AIM  481  ISA  A  PROTOTYPE  INTELLIGENT  SCHEDULING  ASSISTANT  F 
DEFENSE  ACQUISITION  MANAGEMENT CU)  AIR  FORCE  INST  OF 
TECH  HRIGHT-PATTERSON  AF  OH  SCHOOL  OF  ENGI 
UNCLASSIFIED  J  L  HORAN  MAR  88  AFIT/GE/ENG/88H-9  F/G  12/9 


i.o  sk  m. 


£  i«  12  0 


L25  11.4 


MICROCOPY  RESOLUTION  TEST  CHART 
N*r,0*At.  au  of  stanojmm* ihj** 


AFIT/GE/ENG/8  8M -  9 


ISA 

A  PROTOTYPE  INTELLIGENT  SCHEDULING  ASSISTANT 
FOR  DEFENSE  ACQUISITION  MANAGEMENT 
THESIS 

Jerry  L.  Moran 
Captain,  USA 

AFIT/GE/ENG/8 8M- 9 


Approved  for  public  release;  distribution  unlimited. 


AFIT/GE/ENG/88M-9 


ISA 

A  PROTOTYPE  INTELLIGENT  SCHEDULING  ASSISTANT 
FOR  DEFENSE  ACQUISITION  MANAGEMENT 


THESIS 


Presented  to  the  Faculty  of  the  School  of  Engineering 


of  the  Air  Force  Institute  of  Technology 


Air  University 


In  Partial  Fulfillment  of  the 
Requirements  for  the  Degree  of 
Master  of  Science  in  Electrical  Engineering 


Jerry  L.  Moran 
Captain,  USA 


March  1988 


I  Acce* 

NTIS 

DTIC 

Unanr 

JustJ 

ssion  For 

GRAftI  Af 

tab 

lounced  q 

if 1 oat ion 

Bv 

distribution/ 

1  Aval 

jDlst 

m 

lability  Codes 

Avail  and/or 
Special 

Approved  for  public  release;  distribution  unlimited. 


This  thesis  Investigated  the  application  of  artificial  Intelligence 
to  defense  acquisition  management.  The  goal  was  to  demonstrate  how 
knowledge -based  methods  could  improve  scheduling  of  defense  acqulstion 
programs.  The  objectives  were  1)  to  determine  the  kind  of  knowledge 
needed  to  tailor  schedules  and  2)  to  develop  a  framework  for  using  that 
knowledge  to  generate  tailored  schedules.  ISA,  a  prototype  Intelligent 
Scheduling  Assistant,  successfully  shows  how  knowledge  used  to  tailor 
program  schedules  can  be  captured  in  a  rule-based  system. 
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Abstract 

This  thesis  investigated  the  application  of  artificial  intelligence 
to  defense  acquisition  management.  The  goal  was  to  demonstrate  how 
knowledge -based  methods  could  improve  scheduling  of  defense  acquisition 
programs.  The  objectives  were  1)  to  determine  the  kind  of  knowledge 
needed  to  tailor  schedules  and  2)  to  develop  a  framework  for  using  that 
knowledge  to  generate  tailored  schedules. 

Scheduling  of  defense  acquisition  programs  is  a  difficult  problem 
for  which  expert  systems  are  an  appropriate  solution  methodology.  This 
thesis  identified  35  characteristics  of  a  defense  acquisition  program 
which  affect  the  applicability,  duration,  and  relationships  of  tasks 
required  to  go  from  receipt  of  a  Program  Management  Directive  to  con¬ 
tract  award.  It  extends  the  model  network  concept  used  in  the  Aeronaut¬ 
ical  Systems  Division  and  the  Air  Force  Acquisition  Logistic  Command  of 
the  United  States  Air  Force. 

ISA,  a  prototype  Intelligent  Scheduling  Assistant,  successfully 
shows  how  knowledge  used  to  tailor  program  schedules  can  be  captured  in 
a  rule-based  system.  ISA  uses  the  values  of  acquisition  program  charac¬ 
teristics  to  generate  tailored  schedules.  The  concept  is  applicable  to 
any  project  schedule. 


ISA 


I 


A  PROTOTYPE  INTELLIGENT  SCHEDULING  ASSISTANT 
FOR  DEFENSE  ACQUISITION  MANAGEMENT 


I ■  Introduction 


Background 

The  average  defense  acquisition  program  experiences  cost  growth  of 
50  percent  to  100  percent  while  program  deliveries  slip  30  percent. 
Cost  growth  and  schedule  slippage  are  due  primarily  to  Instability  in 
establishing  requirements,  planning,  and  budgeting  for  weapon  systems. 
(Gamier,  1986:1) 

Scheduling  can  reduce  Instability  In  a  program.  Scheduling  is  a 
process  of  deciding  what  work  needs  to  be  done,  who  will  be  responsible 
for  the  work,  when  the  work  should  be  done,  and  what  order  the  work 
should  be  done  In.  Network  schedules  provide  graphical  representations 
of  plans  which  can  be  used  to  indicate  progress,  identify  problems,  and 
aid  communications  (Wofflnden,  1987). 

Despite  Its  advantages,  scheduling  is  difficult  because  no  two 
defense  acquisition  programs  are  the  same.  This  variability  makes  it 
difficult  to  decide  what  work  Is  needed,  who  should  be  responsible,  how 
long  It  should  take,  and  what  order  it  should  be  done  in.  Experience  is 
often  the  best  guide  to  developing  a  schedule.  However,  due  to  the  high 
rotation  rate  among  both  military  and  civilian  personnel,  many  people 
assigned  to  defense  acquisition  programs  are  new  and  inexperienced  (Gan- 
sler ,  1986:9). 
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The  Aeronautical  Systems  Division  (ASD)  of  the  Air  Force  Systems 
Command  (AFSC)  uses  model  networks  (schedules)  to  alleviate  problems 
caused  by  inexperience.  Model  networks  (described  further  in  Chapter 
II)  attempt  to  capture  the  expertise  of  experienced  program  personnel. 
Model  networks  must  be  tailored  to  specific  programs.  Tailoring  is  the 
process  of  deciding  which  tasks  apply,  specifying  who  is  responsible  for 
each  task,  estimating  how  long  each  task  takes,  and  making  appropriate 
changes  in  the  order  of  the  tasks. 

Problem 

Model  networks  are  difficult  to  use  because  they  are  too  general 
and  lack  sufficient  tailoring  guidance.  Model  networks  include  every 
conceivable  task  that  may  occur  in  the  program  schedule.  Some  of  these 
tasks  are  mutually  exclusive  and  may  not  occur  In  the  same  network. 
Suggested  task  durations  may  vary  widely.  Unfortunately,  model  networks 
lack  sufficient  guidance  to  help  inexperienced  personnel  make  tailoring 
decisions.  Thus,  users  often  find  tailoring  model  networks  to  be  a 
difficult  and  time-consuming  process. 

The  goal  of  this  thesis  was  to  demonstrate  how  knowledge -based 
methods  could  improve  scheduling  of  defense  acquisition  programs.  The 
objectives  were  1)  to  determine  the  kind  of  knowledge  needed  to  tailor 
schedules  and  2)  to  develop  a  framework  for  using  that  knowledge  to 
generate  tailored  schedules. 

Scope 

This  thesis  developed  a  demonstration  prototype  for  generating 


tailored  schedules  for  awarding  defense  contracts. 


Approach 


An  existing  model  network  consisting  of  48  tasks  and  covering  28 
months  was  used  as  a  starting  point  for  this  thesis.  The  thesis  effort 
was  divided  into  the  six  distinct  phases  typical  of  many  knowledge -based 
system  developments.  These  phases  were  problem  assessment,  knowledge 
acquisition,  prototype  design,  tool  selection,  prototype  development, 
and  prototype  evaluation. 

The  problem  assessment  phase  was  used  to  acquire  a  thorough  under¬ 
standing  of  the  scheduling  and  tailoring  processes.  A  literature 
search,  focusing  on  project  scheduling,  was  used  to  gain  a  better  under¬ 
standing  of  scheduling  techniques.  Program  management  personnel,  de¬ 
fense  contractors,  and  individuals  with  scheduling  knowledge  were  inter¬ 
viewed  to  gain  their  insights  on  the  use  of  network  schedules  and  model 
networks.  The  data  collected  was  used  to  assess  the  potential  for  de¬ 
veloping  an  expert  system  for  generating  tailored  schedules. 

The  knowledge  acquisition  phase  was  used  to  determine  the  specific 
knowledge  needed  to  make  tailoring  decisions.  Program  management  per¬ 
sonnel  were  interviewed  to  identify  the  kinds  of  data,  knowledge,  and 
procedures  used  to  tailor  tasks  in  the  48 -task  model  network. 

The  prototype  design  phase  was  used  to  establish  system  require¬ 
ments  and  design  the  demonstration  prototype.  The  design  was  approached 
from  a  functional  point  of  view  and  considered  twelve  principles  for  the 
design  of  interactive  computer  systems. 

The  tool  selection  phase  was  used  to  select  tools  for  the  demon¬ 
stration  prototype.  Tool  selection  was  based  on  availability,  power, 
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sophistication,  support  facilities,  reliability,  maintainability,  and 
tool  features. 

The  prototype  development  phase  was  used  to  develop  the  demonstra¬ 
tion  prototype.  The  prototype  implements  that  subset  of  the  system  re¬ 
quirements  deemed  necessary  to  demonstrate  the  feasibility  of  an  oper¬ 
ational  system.  The  prototype  was  developed  using  an  incremental  ap¬ 
proach. 

The  prototype  evaluation  phase  was  used  to  evaluate  the  demonstra¬ 
tion  prototype.  The  prototype  was  evaluated  by  testing  its  ability  to 
generate  tailored  schedules.  The  prototype  was  also  evaluated  by  poten¬ 
tial  users . 

Sequence  of  Presentation 

Chapter  II  reviews  conventional  scheduling  methods,  computer-based 
scheduling  tools,  model  networks,  and  knowledge -based  scheduling  tech¬ 
niques.  Chapter  III  assesses  the  potential  for  using  expert  systems  to 
solve  scheduling  problems  in  ASD/RW  (Deputy  for  Reconnaissance/Strike 
and  Electronic  Warfare).  Chapter  IV  describes  the  knowledge  acquisition 
process.  Chapter  V  discusses  system  requirements,  prototype  design,  and 
tool  selections.  Chapter  VI  describes  the  implementation  of  the  proto¬ 
type.  Chapter  VII  presents  the  results  of  the  prototype  evaluation. 
Chapter  VIII  summarizes  the  results  of  the  thesis  and  makes  recommenda¬ 


tions  for  further  research. 


Overview 

This  chapter  reviews  conventional  scheduling  methods,  computer- 
based  scheduling  tools,  model  networks,  and  knowledge -based  scheduling 
techniques.  Schedules  are  typically  represented  using  bar  charts  or 
activity  networks.  The  most  popular  form  of  bar  chart  is  the  Gantt 
chart.  Activity  networks  are  used  In  the  Critical  Path  Method  (CPM)  and 
the  Program  Evaluation  and  Review  Technique  (PERT).  A  wide  variety  of 
computer-based  scheduling  tools  which  use  bar  charts  and/or  activity 
networks  have  been  developed.  Model  networks  are  used  by  ASD  and  others 
to  augment  PERT-based  schedule  development.  Researchers  in  artificial 
intelligence  have  investigated  techniques  for  developing  knowledge -based 
plans  and  schedules. 

gant£  Charts 

During  World  War  I,  Henry  L.  Gantt  developed  the  Gantt  chart  as  a 
visual  aid  for  monitoring  production  performance.  Gantt  charts  show 
activities  In  the  form  of  a  bar  chart  and  became  an  accepted  business 
tool  by  World  War  II  (Fersko-Welss ,  1987:166).  They  are  used  to  show 
the  progress  of  individual  activities  In  relation  to  a  fixed  time  scale 
and  exist  in  many  forms. 

Gantt  charts  offer  three  main  advantages.  They  graphically  show 


the  important  activities  without  clutter  and  detail,  graphically  show 
the  progress  of  activities  with  respect  to  time,  and  are  easy  to  read 
and  understand.  (Wofflnden,  1987) 


Gantt  charts  have  two  main  disadvantages.  They  do  not  explicitly 
show  inter-relationships  between  activities  or  the  dynamics  of  activit¬ 
ies.  (Woffinden,  1987) 

PERT/CPM  Networks 

Dr.  John  Mauchly  developed  CPM  in  the  late  1950s  to  identify  criti¬ 
cal  tasks  in  a  project.  Critical  tasks  are  those  activities  that  must 
be  completed  on  time  in  order  to  meet  project  deadlines.  PERT,  devel¬ 
oped  by  Willard  Frazer,  calculates  activity  durations  using  three  esti¬ 
mates  -  best  case,  worst  case  and  most  likely  case.  Both  CPM  and  PERT 
use  flow  diagrams  (activity  networks  commonly  referred  to  as  PERT  net¬ 
works)  to  represent  the  schedule.  (Fersko-Weiss ,  1987:166) 

PERT  networks  offer  several  advantages.  They  aid  communication  by 
graphically  showing  the  work  to  be  done,  who  is  responsible,  activity 
durations,  and  inter-relationships  between  activities.  They  improve  the 
understanding  of  complex  projects  when  activities  are  clearly  understood 
and  valid  durations  can  be  estimated.  Most  important,  they  help  identi¬ 
fy  potential  problems  by  showing  the  impact  of  late  tasks  on  the  sched¬ 
ule.  (Woffinden,  1987) 

PERT  networks  have  some  disadvantages.  They  require  accurate  dura¬ 
tion  estimates,  are  difficult  to  use  manually  for  complex  projects,  and 
do  not  address  the  dynamics  of  project  activities.  (Woffinden,  1987) 

Computer-based  Scheduling  Tools 

Computer  programs  for  project  management  were  first  developed  in 
the  1950s  during  the  U.S.  Navy's  Polaris  project.  Commercial  marketing 
of  mainframe  software  for  CPM  applications,  used  primarily  to  manage 


large  projects  In  construction,  started  in  the  1960s.  The  first  commer¬ 
cial  personal  computer  (PC)  version  of  project  management  software,  the 
Harvard  Project  Manager,  was  introduced  in  1983.  More  than  100  PC-based 
project  management  programs,  ranging  from  $35  to  almost  $8000,  are  com¬ 
mercially  available  today.  (Fersko-Weiss ,  1987:153,166) 

The  Air  Force  Acquisition  Logistics  Command  (AFALC)  developed  the 
Computer  Supported  Network  Analysis  System  (CSNAS)  as  a  PERT/CPM-based 
interactive  scheduling  system  for  program  management.  CSNAS  currently 
has  more  than  100  users,  is  written  in  FORTRAN,  and  is  available  in 
mainframe  (HP3000  and  VAX)  and  PC  (IBM-compatible  and  Zenith)  versions. 
(Clark,  1987) 

The  Defense  Systems  Management  College  (DSMC)  is  developing  the 
Program  Manager's  Support  System  (PMSS)  to  support  the  decision-making 
process  of  the  PM.  Designed  for  Zenith  and  IBM- compatible  PCs,  PMSS 
uses  decision  support  systems  technology.  PMSS  contains  modules  that 
develop  Gantt  charts,  develop  PERT  networks,  perform  risk  analysis,  and 
do  milestone  management.  (Scanlon  and  Schutt,  1987) 

All  computer-based  scheduling  tools  require  the  user  to  determine 
and  input  activities,  durations  and  relationships  for  a  project.  The 
software  determines  timing  and  produces  a  graphical  representation  of 
the  project  schedule  based  on  these  inputs.  Thus,  the  user  must  make 
all  scheduling  and  tailoring  decisions  independent  of  the  project  man¬ 
agement  software  used. 

Model  Networks 


CSNAS  contains  a  database  of  model  networks  for  weapons  system 
acquisition  programs  (AFALC,  1987:234).  Various  organizations  in  ASD 


have  developed  their  own  model  networks  for  Internal  use.  A  model  net¬ 
work  typically  consists  of  a  CSNAS  data  file,  a  PERT  network,  and  a  set 
of  reference  sheets.  The  CSNAS  data  file,  containing  the  schedule  in¬ 
formation,  can  be  copied  and  tailored  to  a  specific  program.  The  PERT 
network  graphically  portrays  the  generic  schedule.  The  reference  sheets 
provide  brief  descriptions  (duration,  participants,  references  and  other 
information)  of  each  task. 

The  Deputy  for  Reconnaissance/Strike  and  Electronic  Warfare 
(ASD/RW)  is  developing  a  model  network  for  long  term  programs  and  train¬ 
ing  new  program  managers  in  ASD/RW.  The  model  network,  split  into  two 
phases,  attempts  to  capture  the  corporate  experiences  of  ASD/RW.  The 
Phase  I  network,  completed  in  August  1985,  covers  48  activities  and  28 
months  from  receipt  of  a  Program  Management  Directive  (PMD)  to  contract 
award.  The  Phase  II  network,  undergoing  validation,  covers  76  activit¬ 
ies  and  8  years  from  contract  award  to  Program  Management  Responsibility 
Transfer  (PMRT).  (Zomes,  1987) 

The  Deputy  for  Aeronautical  Equipment  (ASD/AE)  used  model  networks 
to  develop  the  Program  Office  Internal  Networking  and  Tracking  System 
(POINTS).  Derived  from  a  historical  review  of  32  programs  in  ASD/AE, 
POINTS  contains  model  networks  for  use  by  program  and  functional  mana¬ 
gers  in  ASD/AE.  (ASD/AE,  1987) 

Model  networks  include  every  conceivable  task  that  may  occur  for  a 
given  defense  acquisition  program.  Some  of  these  tasks  are  mutually 
exclusive  and  may  not  occur  in  the  same  network.  Some  task  durations 
vary  up  to  a  year  between  pessimistic  and  optimistic  estimates.  Unfor¬ 
tunately,  model  networks  offer  little  tailoring  guidance  to  the  user. 


Thus,  model  networks  are  difficult  and  time-consuming  for  the  inexperi¬ 
enced  person  to  use,  and  they  have  failed  to  gain  acceptance  by  their 
intended  users. 


Knowledge -based  Scheduling  Techniques 

Scheduling  is  a  difficult,  knowledge-intensive  problem  for  two  main 
reasons.  First,  many  potential  schedules  may  be  developed  using  differ¬ 
ent  combinations  of  tasks,  durations,  and  relationships.  Second,  the 
evaluation  of  the  quality  of  a  schedule  is  hard  to  assess.  (Fox,  B.R. 
and  Kempf ,  1985:487-488) 

Early  Al  research  focused  on  developing  general  techniques  for 
solving  problems.  The  General  Problem  Solver  (GPS)  uses  states,  dif¬ 
ferences  between  states,  and  operators  for  changing  states  to  represent 
problems.  The  key  to  solving  a  problem  using  GPS  is  to  select  operators 
which  reduce  the  differences  between  the  current  state  and  the  goal 
state.  The  Stanford  Research  Institute  implemented  GPS  in  STRIPS  -  a 
system  for  generating  plans  as  a  sequence  of  operators.  (Winston, 
1977:131,137-143) 

Sacerdoti  used  procedural  networks  to  show  that  plans  could  be 
created  that  allow  operations  to  execute  in  parallel.  His  approach, 
implemented  in  Nets  of  Action  Hierarchies  (NOAH),  recursively  expands  a 
goal  step  into  a  network  of  sub -steps  which  achieve  the  goal.  Procedur¬ 
al  networks  are  similar  in  structure  to  PERT  networks.  (Sacerdoti, 
1975:206-208) 

Procedural  networks  have  been  enhanced  for  a  number  of  knowledge - 
based  planners/schedulers.  NONLIN  (Non-linear  planner)  was  developed  by 


Tate  as  an  aid  for  constructing  project  networks  (Tate,  1977).  Wilkins 
and  Robinson  developed  SIPE  (System  for  Interactive  Planning  and  Execu¬ 
tion)  as  a  domain- independent  interactive  planner  (Wilkins  and  Robinson, 
1981),  PLANNER'S  WORKBENCH,  developed  by  a  group  headed  by  Hayes-Roth, 
is  an  aid  for  re-planning  (Hayes-Roth  and  others,  1981).  DEVISER,  a 
general-purpose  planner/scheduler  bi*±i-t  by  Vere,  provides  a  capability 
for  adding  time  constraints  to  a  procedural  network  (Vere,  1983). 

Fox  used  constraint-directed  search  in  ISIS  (Intelligent  Scheduling 
and  Information  System)  to  construct  job- shop  schedules.  He  discovered 
that  human  schedulers  spend  80-90%  of  their  time  trying  to  determine 
what  constraints  apply  to  schedule  generation.  ISIS  was  designed  to 
develop  schedules  that  satisfy  as  many  constraints  as  possible  in  near 
real-time.  (Fox,  Mark  S.,  1983) 

Many  other  knowledge -based  planning/scheduling  techniques  have  been 
investigated.  Hayes-Roth  simulated  errand-planning  using  a  blackboard 
approach  (Hayes-Roth  and  others,  1979).  Fukumori  generated  train  sched¬ 
ules  using  range-constriction  search  (Fukumori,  1980).  Gazdik  combined 
fuzzy  sets  and  graph  theory  in  FNET  to  handle  uncertainty  associated 
with  scheduling  (Gazdik,  1983).  Sage  used  multiple  criteria  decision 
making  to  solve  scheduling  problems  (Sage,  1984).  Newman  and  Kemp*'  used 
opportunistic  scheduling  to  develop  schedules  for  a  robot  that  tends 
machines  in  a  manufacturing  plant  (Newman  and  Kempf,  1985). 

Summary 

The  most  popular  conventional  scheduling  techniques  are  Gantt 
charts  and  CPM/PERT  networks.  Gantt  charts  are  easy  to  understand  while 
CPM/PERT  networks  povide  a  better  graphical  representation  of  complex 
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projects.  A  wide  variety  of  commercial  and  public  domain  project  man¬ 
agement  software  is  available  to  handle  the  actual  mechanics  of  comput¬ 
ing  schedule  timing  and  producing  network  drawings.  However,  the  user 
must  make  all  schedule  and  tailoring  decisions  prior  to  using  the  soft¬ 
ware.  ASD  uses  model  networks  to  give  the  user  a  starting  point  for 
making  schedule  decisions.  However,  difficulties  in  tailoring  the  model 
networks  have  led  to  a  general  lack  of  acceptance. 

AI  research  focuses  on  the  use  of  knowledge  to  develop  plans  and 
schedules.  Procedural  networks  have  been  used  extensively  to  develop 
general-purpose  planners/schedulers.  Constraint-directed  search  has 
been  used  to  develop  job -shop  schedules  which  satisfy  as  many  cons¬ 
traints  as  possible  in  near  real-time.  Many  other  knowledge -based 
scheduling  techniques  have  been  investigated. 

This  thesis  uses  knowledge -based  techniques  to  extend  the  model 
network  concept.  The  prototype  Intelligent  Scheduling  Assistant  (ISA) 
generates  tailored  schedules  using  program  knowledge  and  task  knowledge. 
The  results  are  exported  to  CSNAS  for  actual  schedule  computation  and 
network  drawings. 


Ill .  Problem  Assessment 

Overview 

This  chapter  assesses  the  potential  for  using  expert  systems  to 
solve  scheduling  problems  in  ASD/RW.  An  experience  survey  was  conducted 
by  interviewing  seventeen  people  with  various  degrees  of  experience  and 
responsibility  for  scheduling.  Four  upper-level  and  middle-level  manag¬ 
ers  in  ASD,  two  program  managers  in  ASD/RW,  three  schedulers  in  ASD,  two 
people  who  worked  on  ASD/RW' s  Phase  I  model  network,  three  contractors 
who  provide  scheduling  support  to  ASD/RW,  and  three  people  outside  of 
ASD  were  interviewed.  The  results  of  the  problem  assessment  interviews 
are  contained  in  Appendix  A. 

The  remainder  of  this  chapter  summarizes  the  results  of  the  inter¬ 
views.  First,  the  current  state  of  scheduling  in  ASD/RW  is  presented. 
Then  the  potential  for  using  expert  systems  to  improve  model  networks  is 
examined  in  terms  of  feasibility,  suitability,  and  desirability.  Final¬ 
ly,  the  results  of  the  problem  assessment  are  summarized  at  the  end  of 
the  chapter. 


Scheduling  in  ASD/RW 

ASD/RW  is  a  matrix  organization  made  up  of  systems  directorates  and 
functional  area  directorates  .  Functional  area  personnel  support  pro¬ 
grams  in  the  systems  directorates.  One  person  may  support  multiple 
programs.  The  systems  directorates  are  Strike  SPO  (RWN) ,  Reconnaissance 
Programs  (RWQ) ,  Directorate  of  Electronic  Combat  (RWW) ,  Inter-Command 
Electronic  Warfare  Management  (RWA) ,  and  Special  Projects  SPO  (RWZ) .  The 


functional  areas  are  Manufacturing  &  Quality  Assurance  (RWD) ,  Engineer¬ 
ing  (RWE) ,  Contracts  (RWK) ,  Logistics  (RWL) ,  Program  Control  (RWP) , 
Safety  (RWS)  and  Acquisition  Support  (RWB) . 


Scheduling  Process . 

Program  management  teams,  consisting  of  a  PM  and  functional  area 
representatives,  are  formed  early  in  a  program.  Some  programs  simply 
use  suspense  calendars  to  keep  track  of  events.  Others  use  milestone 
charts  to  schedule  the  program.  The  teams  that  use  network  schedules 
usually  tailor  schedules  from  similar  programs  or  build  a  schedule  from 
scratch.  Some  programs  hire  contractors  to  do  scheduling.  Only  two 
instances  were  found  where  a  team  had  tried  to  use  the  Phase  I  network. 
Both  of  these  efforts  failed. 

When  modifying  the  Phase  I  network,  the  program  management  team 
analyzed  network  tasks,  durations,  and  relationships.  The  analysis  was 
done  individually  or  in  team  meetings.  Tasks  were  reviewed  to  determine 
which,  if  any,  did  not  apply  to  the  program.  New  tasks  were  added  to 
the  network  during  the  review  process.  Task  durations  were  reviewed  to 
determine  if  changes  were  needed.  Task  relationships  were  examined  for 
changes  which  would  maximize  parallel  execution  of  tasks.  The  schedule 
was  modified  to  reflect  all  changes,  and  the  review  process  iterated 
until  a  general  consensus  was  reached. 

Both  efforts  at  using  the  Phase  I  network  failed  due  to  insuffic¬ 
ient  tailoring  guidance.  Although  a  reasonable  approach  was  used,  most 
members  of  the  team  lacked  sufficient  experience  to  select  appropriate 
tasks,  durations,  and  relationships.  Thus,  tailoring  the  network  proved 
to  be  a  difficult  and  time-consuming  task  that  ultimately  failed. 


Four  factors  contribute  to  scheduling  problems  in  ASD/RW.  First, 
most  programs  lack  people  who  are  experienced  in  developing  schedules. 
Second,  schedules  are  used  improperly.  Third,  programs  operate  with 
limited  resources  and  manpower.  Fourth,  many  defense  acquisition  pro¬ 
grams  are  in  a  constant  state  of  flux. 

Most  programs  lack  people  who  are  experienced  in  developing  sched¬ 
ules.  The  Phase  I  model  network  was  conceived  to  leverage  the  corporate 
experience  in  ASD/RW  and  give  inexperienced  people  a  starting  point  for 
developing  schedules.  However,  many  program  personnel  are  unaware  of 
the  Phase  1  network.  Others  do  not  use  the  Phase  I  network  because  they 
find  it  too  difficult  and  time-consuming  to  tailor  the  network  and/or 
use  CSNAS.  Clearly,  the  Phase  I  network  has  failed  to  gain  acceptance 
from  its  intended  users. 

Schedules  are  used  improperly  due  to  misunderstandings  of  the  pur¬ 
pose  of  network  schedules.  A  common  error  is  to  artificially  change 
durations  and/or  relationships  to  reduce  schedule  length.  Another  error 
is  to  artificially  increase  activity  durations  to  provide  a  buffer 
against  unforeseen  problems.  In  either  case,  the  purpose  of  the  sched¬ 
ule  is  defeated  since  it  does  not  accurately  reflect  program  plans. 
Network  schedules  should  be  used  to  determine  program  status  and  identi¬ 
fy  potential  problems.  Early  identification  allows  the  manager  to  act 
to  avoid  known  problems  rather  than  react  to  unforeseen  problems  using 
"crisis  management". 

Programs  operate  with  limited  resources  and  manpower.  Meanwhile, 
the  creation  of  schedules  is  a  time-consuming  and  manpower- intensive 


process.  Thus,  even  program  managers  who  would  like  to  use  network 
schedules  are  often  unable  to  due  to  a  lack  of  resources.  In  cases 
where  funding  is  available  to  hire  contractors,  program  personnel  must 
devote  time  to  coordinating  with  the  contractor  if  the  schedule  is  to 
accurately  reflect  the  status  of  the  program. 

Many  defense  acquisition  programs  are  in  a  constant  state  of  flux. 
Rapidly  changing  requirements  complicate  the  maintenance  of  accurate 
schedules.  Good  schedules  are  quickly  made  obsolete  unless  efforts  are 
made  to  maintain  and  update  schedules  on  a  periodic  basis.  Some  changes 
in  requirements  may  require  wholesale  changes  in  the  schedule.  Due  to 
the  lack  of  resources,  schedules  tend  to  be  ignored  until  they  are  in¬ 
valid. 

Scheduling  Impact . 

Schedule  development  and  maintenance  is  a  time-consuming  and  man¬ 
power-intensive  process.  It  takes  weeks  of  coordination  effort  to  de¬ 
velop  a  realistic  program  schedule.  Considerably  more  effort  is  needed 
to  manage  and  maintain  a  schedule.  Regardless  of  the  cause,  unrealistic 
program  schedules  lead  to  increased  program  costs  and  unforeseen  sched¬ 
ule  delays. 

Expert  System  Potential 

A  conventional  computer  program  manipulates  data  using  algorithms. 
A  knowledge -based  system  is  a  computer  program  that  manipulates  know¬ 
ledge  using  heuristics.  An  expert  system  is  a  knowledge -based  system 
which  performs  at  the  level  of  an  expert  in  a  specific  problem  domain. 
(Waterman,  1986:24-30) 
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Expert  systems  could  reduce  problems  of  Inexperience  by  capturing 
the  corporate  knowledge  and  experiences  of  ASD/RW.  Expert  systems  could 
reduce  unintentional  misuse  of  schedules  by  generating  realistic  sched¬ 
ules  based  on  program  knowledge  and  task  knowledge.  Expert  systems 
could  be  used  to  suggest  alternatives  for  resolving  schedule  problems. 
Expert  systems  could  reduce  resource  requirements  for  schedule  develop¬ 
ment  by  reducing  the  demand  on  experienced  personnel  within  ASD/RW. 
Expert  systems  could  facilitate  schedule  changes  caused  by  changes  In 
requirements.  Expert  systems  could  Improve  the  quality  and  consistency 
of  schedule  development. 

Each  of  the  scheduling  problems  addressed  are  Inter-related.  How¬ 
ever,  the  remainder  of  this  assessment  will  focus  on  the  lack  of  exper¬ 
ience  In  developing  schedules.  In  particular,  the  potential  for  using 
expert  systems  to  Improve  model  networks  will  be  assessed. 

Waterman  suggests  that  expert  systems  should  be  considered  only 
when  expert  systems  are  possible,  appropriate,  and  justified  (Waterman, 
1986:127).  Similarly,  Prerau  offers  more  than  fifty  factors  to  consider 
when  evaluating  potential  expert  system  applications  (Prerau,  1985:26- 
30) .  The  factors  suggested  by  both  authors  boll  down  to  evaluating  the 
feasibility,  suitability  and  desirability  of  building  an  expert  system. 
Thus,  the  potential  for  using  expert  systems  to  improve  model  networks 
is  evaluated  in  terms  of  feasibility,  suitability  and  desirability. 

Feasibility, 

Building  an  expert  system  Is  feasible  when  expertise  is  available 
to  the  developer  and  current  expert  system  technology  enables  the  devel¬ 
oper  to  capture  the  expertise  in  a  computer  program.  Although  expertise 


might  exist,  the  developer  may  not  have  access  to  it  when  the  expert  is 
inarticulate  or  unavailable.  Expertise  can  be  captured  using  current 
technology  for  problems  which  require  primarily  cognitive  skills,  can  be 
taught  to  inexperienced  personnel,  and  take  from  a  few  minutes  to  a  few 
hours  to  solve.  (Waterman,  1986:128-129  and  Prerau,  1985:26-30) 

Expertise  is  not  specifically  available  for  tailoring  the  Phase  I 
model  network.  However,  a  wealth  of  knowledge  and  experience  for  se¬ 
lecting  tasks,  durations  ,  and  relationships  is  available  from  experi¬ 
enced  program  managers  and  functional  area  personnel.  Regulations, 
policy  letters,  and  operating  instructions  provide  another  source  of 
knowledge.  The  Phase  I  network  itself  contains  a  great  deal  of  know¬ 
ledge  about  required  tasks,  durations  and  relationships. 

The  expertise  needed  to  make  schedule  decisions  can  be  captured 
using  current  AI  technology.  Scheduling  requires  only  cognitive  skills 
and  can  be  taught  to  inexperienced  personnel.  Scheduling  can  be  decom¬ 
posed  into  manageable  sub -tasks  which  take  a  few  minutes  to  a  few  hours 
to  solve. 

An  expert  system  is  feasible.  Although  experts  for  tailoring  the 
Phase  I  network  do  not  exist,  ASD/RW  has  many  individuals  who  are  exper¬ 
ienced  in  various  aspects  of  the  acquisition  process.  Thus,  an  expert 
system  can  be  built  to  generate  schedules  by  combining  the  knowledge  of 
these  individuals. 

Suitability. 


Building  an  expert  system  is  suitable  when  the  nature  of  the  prob¬ 
lem  makes  Al  solutions  appropriate  and  the  system  is  appropriate  for 
implementation.  AI  solutions  are  appropriate  when  the  domain  is  rela- 


tively  stable,  symbolic  manipulation  is  required,  heuristics  are  used, 
the  problem  is  not  trivial,  and  an  explanation  capability  is  desired. 
Expert  systems  are  appropriate  for  Implementation  when  the  system  can  be 
phased  in  over  time,  non-optlmal  solutions  are  acceptable,  and  the  sys¬ 
tem  is  testable.  (Waterman,  1986:128-129  and  Prerau,  1985:26-30) 

AI  solutions  are  appropriate  for  scheduling  defense  acquisitions. 
Although  schedules  may  change  quite  often,  scheduling  knowledge  such  as 
regulatory  requirements  changes  much  less  often.  Thus,  defense  acquisi¬ 
tion  provides  a  relatively  stable  domain.  Scheduling  requires  symbolic 
manipulation  and  uses  heuristics  to  achieve  solutions.  It  takes  years 
of  experience  to  develop  proficiency  in  scheduling.  The  ability  to 
document  decisions  and  provide  explanations  is  desirable. 

An  expert  system  is  appropriate  for  implementation  in  ASD/RW.  The 
expert  system  could  be  phased  in  over  time  as  knowledge  bases  are  devel¬ 
oped  for  each  functional  area.  Non- optimal  solutions  are  acceptable. 
Indeed,  since  requirements  and  funding  are  likely  to  change,  the  genera¬ 
tion  of  an  optimal  schedule  is  not  needed.  The  greatest  difficulty  for 
implementation  lies  in  the  testing  of  the  expert  system.  Because  a 
unique  correct  solution  for  any  program  does  not  exist,  the  reasonable¬ 
ness  of  any  solution  is  a  subjective  judgment.  The  subjectiveness  of 
the  solution  makes  explanation  capabilities  very  important  when  the 
solution  is  reviewed  for  acceptability. 

An  expert  system  is  suitable.  Scheduling  is  a  non-trivial  problem 
which  demands  the  use  of  heuristics.  Due  to  the  subjective  nature  of 
solutions,  explanation  facilities  are  important.  An  expert  system  could 
be  phased  in  and  non-optimal  solutions  are  acceptable. 


Building  an  expert  system  is  desirable  when  a  need  for  the  expert 
system  exists,  benefits  can  be  shown,  and  resources  are  available  both 
to  develop  and  maintain  the  expert  system.  Expert  systems  are  not  need¬ 
ed  when  expertise  is  readily  available  and  relatively  inexpensive.  The 
benefits  of  an  expert  system  should  outweigh  the  costs  of  development 
and  maintenance.  (Waterman,  1986:128-129  and  Prerau,  1985:26-30) 

A  need  for  the  expert  system  exists.  ASD/RW  is  responsible  for 
more  than  30  defense  acquisition  programs  and  lacks  sufficient  numbers 
of  experienced  schedulers  to  cover  all  of  these  programs.  They  also 
lack  sufficient  funding  to  contract  out  scheduling  for  all  of  the  pro¬ 
grams.  Thus,  an  expert  system  would  help  leverage  the  corporate  experi¬ 
ence  in  ASD/RW. 

An  expert  system  could  provide  a  variety  of  benefits.  It  could 
save  the  time  of  experienced  personnel  and  reduce  coordination  efforts. 
It  could  provide  a  degree  of  consistency  in  schedule  generation.  It 
could  provide  a  record  of  the  decision  process  that  could  be  used  when 
reviewing  the  schedule  for  endorsement. 

ASD/RW  has  limited  resources  for  expert  system  development  and 
maintenance.  However,  a  prototype  expert  system  can  be  developed  with 
current  resources.  ASD  currently  has  sufficient  computer  resources  to 
support  the  development  and  maintenance  of  an  operational  expert  system. 
The  price  of  expert -system  building  tools  range  from  a  few  thousand  to 
many  thousands  of  dollars.  Development  and  maintenance  would  require 
one  or  two  people  to  work  full-time. 


An  expert  system  is  desirable.  A  need  for  the  expert  system 
exists,  the  benefits  appear  to  outweigh  the  costs,  and  the  organization 


has  sufficient  resources. 

Summary 

Expert  systems  would  be  useful  for  alleviating  scheduling  problems 
in  ASD/RW.  They  could  capture  corporate  knowledge  and  experiences, 
reduce  unintentional  misuse  of  schedules ,  reduce  resource  requirements 
of  schedule  development,  facilitate  schedule  changes  caused  by  changes 
in  requirements,  and  improve  the  quality  and  consistency  of  schedules. 
An  expert  system  is  feasible,  suitable,  and  desirable. 


Overview 


This  chapter  reviews  the  approach  used  to  acquire  the  knowledge 
needed  for  an  Intelligent  Scheduling  Assistant  (ISA).  The  planned  ap¬ 
proach  was  to  investigate  the  use  of  the  Phase  I  network  using  a  combin¬ 
ation  of  on-site  observation,  problem  discussion,  and  problem  analysis. 
On-site  observation  involves  watching  the  expert  solve  real  problems  on 
the  job;  problem  discussion  explores  the  kind  of  data,  knowledge,  and 
procedures  needed  to  solve  specific  problems;  and  problem  analysis  re¬ 
quires  the  expert  to  solve  realistic  problems  while  explaining  his  ra¬ 
tionale  (Waterman,  1987:156-160) 

The  problem  assessment  phase  revealed  that  the  Phase  I  network  had 
not  been  accepted  by  its  intended  users.  Only  two  cases  were  discovered 
where  the  Phase  I  network  had  been  used.  Both  of  these  efforts  failed. 
Clearly,  experts  in  tailoring  the  Phase  I  network  do  not  exist.  Thus, 
on-site  observation  and  problem  analysis  could  not  be  used  to  obtain 
knowledge  about  tailoring  the  Phase  I  network. 

Despite  the  problems,  the  approach  described  for  using  the  Phase  I 
network  seemed  reasonable.  Members  of  the  project  team  would  analyze 
each  task  individually  to  determine  its  applicability,  duration,  and 
relationship  to  other  tasks  in  the  networks.  Modifications  were  made 
where  deemed  appropriate.  A  team  approach  was  necessary  because  no 
single  individual  knew  enough  about  the  entire  acquisition  process  to 
tailor  the  complete  network.  Thus,  ISA  proved  to  be  a  multiple  expert 
problem. 


Problem  discussion  became  the  primary  method  of  knowledge  acquisi¬ 
tion.  Two  program  managers,  six  people  from  RWK,  six  from  RWE,  five 
from  other  divisions,  and  two  external  to  RW  were  interviewed  to  obtain 
tailoring  knowledge  for  each  task  in  the  Phase  I  network.  Appendices  B 
and  C  contain  the  results  of  the  knowledge  engineering  interviews.  The 
remainder  of  this  chapter  describes  the  conduct  of  the  interviews  and 
summarizes  the  results. 

Knowledge  Engineering  Interviews 

People  were  selected  for  knowledge  engineering  interviews  in  three 
ways.  First,  people  interviewed  during  the  problem  assessment  phase 
were  asked  to  recommend  Individuals  who  were  knowledgeable  in  different 
functional  areas.  Second,  some  knowledge  engineering  interviews  led  to 
referrals  to  other  people  who  were  deemed  to  be  better  qualified  in  some 
aspect  of  the  problem.  Third,  functional  area  supervisors  were  contact¬ 
ed  for  assistance  with  tasks  which  were  not  adequately  covered  by  refer¬ 
rals. 

Knowledge  engineering  interviews  focused  on  each  task  in  isolation. 
Individuals  were  asked  for  criteria  which  could  be  used  to  determine 
task  applicability,  duration  and  relationships.  First,  the  individual 
being  Interviewed  was  asked  under  what  circumstances  a  task  would  not  be 
applicable.  Once  applicability  criteria  were  established,  the  individ¬ 
ual  was  asked  how  reasonable  durations  would  be  estimated.  Finally, 
individuals  were  asked  to  comment  on  the  task  relationships  defined  in 


the  Phase  I  network. 


Knowledge 


Results 


Knowledge  engineering  interviews  re-emphasized  the  lack  of  accept¬ 
ance  of  the  Phase  I  network  in  ASD/RW.  Most  of  the  individuals  inter¬ 
viewed  were  unaware  of  its  existence.  Others  knew  something  about  the 
effort  but  were  unfamiliar  with  the  result. 

Knowledge  engineering  interviews  focused  on  the  48  tasks  contained 
in  the  Phase  I  network.  One  of  these  tasks  was  dismissed  as  inappropri¬ 
ate,  three  were  combined  with  other  tasks,  and  eight  new  tasks  were 
identified.  Most  of  the  additions  were  the  result  of  expanding  single 
tasks  into  two  or  more  tasks.  A  complete  listing  of  the  tasks  is  con¬ 
tained  in  Appendix  B. 

Although  some  individuals  were  able  to  clearly  define  criteria  for 
making  tailoring  decisions,  most  found  it  difficult.  This  is  a  major 
obstacle  to  the  development  of  an  expert  system  because  the  quality  of 
the  schedule  is  dependent  on  the  quality  of  the  knowledge  in  the  system. 
However,  the  purpose  of  this  thesis  was  to  demonstrate  how  knowledge- 
based  techniques  could  be  used  to  construct  ISA.  Since  the  technique 
for  generating  the  schedule  is  not  dependent  on  specific  program  and 
task  knowledge,  the  quality  of  the  knowledge  collected  was  not  critical. 

People  who  were  reluctant  to  offer  criteria  were  told  that  the 
accuracy  of  the  knowledge  was  not  critical  during  initial  stages  of 
development.  The  criteria  offered  would  serve  as  parameters  which  could 
be  tuned  based  on  historical  data  or  other  knowledge  once  the  system  was 
built.  Criteria  which  were  deemed  unnecessary  could  be  deleted  with 
minimal  impact  on  system  performance.  Every  effort  was  made  to  define 
criteria  in  precise  terms. 


Thirty- five  program  characteristics  were  defined  for  use  in  tailor¬ 
ing  various  tasks .  Thirteen  of  these  criteria  affect  the  applicability 
of  twenty- three  tasks.  For  example,  follow-on  programs  do  not  require  a 
New  Start  Review.  The  remainder  of  the  criteria  (and  some  of  the  previ¬ 
ous  thirteen)  affect  task  durations.  A  complete  listing  of  program 
characteristics  is  contained  in  Appendix  C. 

Summary 

Problem  discussion  was  the  primary  method  used  for  acquiring  know¬ 
ledge.  Knowledge  engineering  interviews  focused  on  the  applicability, 
duration,  and  relationships  of  individual  tasks.  Thirty-five  parameters 
were  identified  for  use  in  generating  a  tailored  schedule. 


V 


Prototype  Design  and  Tool  Selection 


Overview 

This  chapter  discusses  system  requirements,  prototype  design,  and 
tool  selections.  System  requirements  are  defined  for  an  operational 
Intelligent  Scheduling  Assistant  (ISA).  The  prototype  design  covers 
that  subset  of  the  system  requirements  deemed  necessary  to  demonstrate 
the  feasibility  of  the  concept.  Tools  were  selected  based  on  system  re¬ 
quirements  and  the  prototype  design. 


System  Requirements 

The  design  goal  for  the  Intelligent  Scheduling  Assistant  Is  to 
improve  the  PM's  ability  to  develop,  maintain,  and  analyze  program 
schedules.  A  conceptual  view  of  an  ISA  is  provided  in  Figure  1. 


Figure  1.  Conceptual  View  of  ISA 
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The  PM  Is  the  Intended  user  of  the  system.  The  user  Interface 
allows  the  PM  to  direct  schedule  development,  modification  and  analysis. 
Schedule  generation  builds  a  schedule  by  selecting  tasks,  durations,  and 
relationships.  Schedule  modification  changes  tasks,  durations,  and 
relationships  in  an  existing  schedule.  Schedule  analysis  computes  sche¬ 
dule  timing  and  suggests  alternatives  for  resolving  schedule  conflicts. 
Separate  knowledge  bases  could  be  used  for  schedule  generation,  schedule 
modification,  and  schedule  analysis.  The  database  maintains  information 
for  defense  acquisition  programs. 

Twelve  design  principles  for  interactive  computer  systems  proposed 
by  Woffinden  (Woffinden,  1984:20-26)  were  considered  while  refining 
system  requirements. 

The  first  design  principle,  determine  the  purpose  of  the  system, 
requires  a  clear  understanding  of  the  problem  before  designing  the  user 
interface.  The  complexity  of  defense  program  management  makes  it  impos¬ 
sible  for  a  single  person  to  understand  all  program  requirements.  This 
complexity  is  complicated  by  frequent  duty  changes  and  changes  in  regul¬ 
atory  requirements.  The  purpose  of  ISA  is  to  help  the  PM  develop,  main¬ 
tain,  and  analyze  program  schedules. 

The  second  design  principle,  know  the  user,  requires  an  understand¬ 
ing  of  the  intended  users.  The  typical  PM  works  long  hours  to  meet 
program  demands,  depends  on  functional  area  personnel  to  provide  task 
inputs,  and  has  little  time  to  learn  new  computer  systems  or  wait  for 
computer  responses.  ISA  should  be  easy  to  use,  provide  feedback  to  the 
user,  and  generate  results  in  less  than  an  hour. 


The  third  design  principle,  identify  resources  available,  involves 
the  choice  of  hardware  and  software.  A  VAX- 780  mainframe  computer,  Z- 
2A8  personal  computers,  expert  system  building  tools,  conventional  pro¬ 
gramming  languages,  scheduling  tools,  and  business  software  tools  are 
available  for  prototype  development.  The  choice  of  hardware  and  soft¬ 
ware  is  detailed  in  the  section  on  tool  selection. 

The  fourth  design  principle,  consider  human  factors,  looks  at  the 
physical  and  psychological  impacts  of  the  system.  ISA  should  minimize 
typing  requirements,  provide  a  menu-driven  interface,  and  use  color  to 
enhance  its  appeal.  Menus  should  be  limited  to  six  options  to  avoid 
overwhelming  the  user  with  choices. 

The  fifth  design  principle,  determine  the  interface  language,  sug¬ 
gests  that  the  system  should  avoid  making  the  user  learn  a  new  and  un¬ 
familiar  language.  The  selection  of  an  interface  language  is  addressed 
In  the  section  on  tool  selection. 

The  sixth  design  principle,  consider  the  environment  of  operation, 
concerns  comfort  and  efficiency.  Since  ISA  Is  designed  for  use  in  an 
office  environment,  no  special  requirements  are  generated  by  considering 
this  principle. 

The  seventh  design  principle,  design  for  evolution,  emphasizes 
providing  for  planned  and  unplanned  changes  to  the  system.  A  modular 
design  should  be  used  facilitate  both  planned  and  unplanned  changes. 

The  eighth  design  principle,  optimize  training,  allows  novices  to 
use  the  system  without  depending  on  experienced  users.  ISA  should  con¬ 
tain  sufficient  prompts  and  help  facilities  to  guide  a  novice  through 
the  scheduling  process. 


The  ninth  design  principle,  accommodate  levels  of  experience,  sug¬ 
gests  different  methods  of  operation  should  be  available  to  the  user. 
ISA  should  provide  separate  modes  of  operation  for  novices  and  experi¬ 
enced  users.  A  novice  mode  should  provide  sufficient  prompts  to  allow 
inexperienced  users  to  develop,  modify,  and  analyze  schedules  without 
the  assistance  of  experienced  users.  An  expert  mode  should  allow  exper¬ 
ienced  users  to  develop,  modify,  and  analyze  schedules  with  minimal 
prompting  and  guidance  from  the  system. 

The  tenth  design  principle,  use  selection  versus  entry,  reduces  the 
demand  on  the  user  to  enter  information.  ISA  should  allow  the  user  to 
select  from  a  list  of  acceptable  responses  where  possible. 

The  eleventh  design  principle,  be  consistent,  refers  to  consistency 
in  operations  throughout  the  system.  Identical  operations  should  be 
invoked  using  the  same  prompts  and  commands  throughout  the  system. 

The  twelfth  principle,  anticipate  errors,  exploits  the  computer's 
ability  to  remember  and  inter-relate  details.  ISA  should  check  for 
errors  and  notify  the  user  of  invalid  inputs. 

Prototype  Design 

The  purpose  of  the  prototype  is  to  demonstrate  the  feasibility  of 
an  Intelligent  Scheduling  Assistant  (ISA)  by  providing  a  user  interface; 
I/O  facilities;  and  methods  for  generating  and  modifying  schedules. 
Actual  schedule  computation  and  drawing  is  provided  by  interfacing  with 
existing  project  management  software.  Table  I  summarizes  the  require¬ 
ments  for  the  demonstration  prototype  and  the  complete  system. 


ISA  uses  a  database  to  maintain  program  information.  A  table  of 
schedule  data  and  a  table  of  program  characteristics  are  associated  with 


each  program.  Schedule  data  consists  of  tasks  (number,  duration,  de¬ 
scription,  start  date,  complete  date,  etc.)  and  relationships  (links) 
between  tasks.  Program  characteristics  are  parameters  (dollar  values, 
type  of  program,  etc.)  that  are  used  to  select  tasks  and  compute  task 
durations.  All  schedule  development  and  modifications  are  done  using 
working  copies  of  the  program  information  associated  with  the  schedule. 


Table  I.  System  Requirements  Matrix 


REQUIREMENT 

DEMONSTRATION 

PROTOTYPE 

COMPLETE 

SYSTEM 

User  interface 

Struc ture 

Completed 

Build  schedules  based  on 
program  characteristics 

Yes 

Yes 

Build  schedules  using  direct 
input  of  task  data 

No 

Yes 

Modify  schedules  based  on  changes 
to  program  characteristics 

Yes 

Yes 

Modify  schedules  by  changing 
task  data 

No 

Yes 

Compute  schedule  timing 

CSNAS 

Yes 

Recommend  alternatives  for 
resolving  schedule  conflicts 

No 

Yes 

ISA  uses  menus  and  explanatory  prompts  to  guide  the  user  through 
the  scheduling  process.  Menu  choices  are  limited  to  six  options  and 
color  is  used  to  enhance  system  appeal.  Default  responses  (where  appli¬ 
cable)  are  offered  and  acceptable  responses  are  listed.  ISA  checks  for 
errors  and  notifies  the  user  of  invalid  responses. 
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ISA  provides  I/O  utilities  to  load  and  save  program  Information. 
The  save  utility  allows  the  user  to  save  program  Information  and  pro¬ 
vides  an  option  to  export  the  data  to  CS NAS.  The  load  utility  makes 
working  copies  of  program  Information  and  provides  an  option  to  Import 
data  from  CSNAS . 

ISA  generates  schedules  using  a  rule  set  and  the  values  of  relevant 
program  characteristics.  ISA  prompts  the  user  for  the  values  of  program 
characteristics  needed  to  generate  a  schedule.  ISA  uses  rules  to  select 
tasks  to  be  Included  in  the  program  schedule  based  on  the  values  of  the 
program  characteristics.  The  rules  add  the  task  to  the  schedule  table, 
compute  the  task  duration,  and  establish  task  links. 

ISA  modifies  schedules  based  on  changes  to  the  values  of  program 


characteristics.  The  user  changes  program  characteristic  values  as 
desired.  Then  ISA  builds  a  new  schedule  using  the  new  values  and  the 
procedure  described  above.  ISA  allows  the  user  to  modify  existing 
schedules  or  create  alternate  schedules  using  this  approach. 


Tool  Selection 

A  Z-248  personal  computer  was  selected  for  the  development  environ¬ 
ment  of  the  prototype.  The  operational  system  could  be  delivered  on 
either  Z-248s  or  the  Automated  Management  System  (AMS)  used  with  the 
VAX-780  In  ASD/RW.  Either  choice  would  make  the  operational  system 
widely  available.  The  AMS  system  would  provide  centralized  control  for 
the  maintenance  of  ISA.  However,  the  availability  of  expert  system 
building  tools,  conventional  programming  languages,  scheduling  tools, 
and  business  software  tools  Is  better  for  the  Z-248s. 
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Guru  was  selected  as  the  tool  for  building  the  demonstration  proto¬ 
type.  Waterman  recommends  evaluating  expert-system  building  tools  In 
terms  of  power  and  sophistication;  support  facilities;  reliability; 
maintainability;  and  tool  features  when  choosing  a  tool  to  use.  (Water¬ 
man,  1986:143).  Guru's  Integrated  package  of  knowledge  processing  capa¬ 
bilities  (expert  systems,  database  management,  screen  management,  pro¬ 
gramming  language,  and  text  processing)  clearly  provide  sufficient  power 
and  sophistication  for  development  of  ISA.  Guru's  support  facilities 
(menu  Interface,  Interactive  environment,  help  facilities,  and  trace 
facilities)  speed  the  development  and  maintenance  of  ISA.  Guru's  reli¬ 
ability  and  maintainability  are  satisfactory.  Guru's  features  are  suff¬ 
icient  for  ISA.  It  provides  a  forward -chaining  Inference  engine  to 
reason  from  program  characteristics  to  schedule  decisions,  a  database  to 
maintain  information  for  defense  acquisition  programs,  and  a  programming 
language  to  implement  the  user  interface. 

CSNAS  was  selected  to  compute  schedule  timing  and  create  schedule 
drawings.  CSNAS  allows  data  exchange  using  data  files,  Is  the  primary 
scheduling  tool  used  in  ASD,  and  was  used  for  the  Phase  I  network. 

Guru  and  CSNAS  are  available  In  PC  and  VAX  versions.  Thus,  use  of 
these  software  tools  makes  the  migration  of  the  system  to  the  AMS  system 
possible  If  desired. 

Summary 

The  design  goal  for  the  Intelligent  Scheduling  Assistant  (ISA)  Is 
to  Improve  the  PM's  ability  to  develop,  maintain,  and  analyze  program 
schedules.  The  purpose  of  the  prototype  Is  to  demonstrate  the  feasibil¬ 
ity  of  the  ISA  concept.  Table  I  summarizes  the  requirements  for  the 


prototype  and  a  complete  system.  The  prototype  uses  a  Z-248  personal 
computer,  Guru,  and  CSNAS. 


The  prototype  was  implemented  in  a  top-down  fashion  using  Guru's 
structured  programming,  screen  management,  database  management,  and 
expert  system  facilities.  Structured  programming  tools  were  used  to 
build  the  framework  of  the  prototype.  Screen  management  facilities  were 
used  to  enhance  the  appearance  of  prompts  for  user  commands  and  data 
input.  Database  facilities  were  used  to  maintain  defense  acquisition 
program  information.  The  CSNAS  import/export  facility  was  built  using  a 
combination  of  programming  tools  and  database  management.  Expert  system 
facilities  were  used  to  build  two  knowledge  bases  -  one  to  prompt  the 
user  for  the  values  of  program  characteristics  and  one  to  generate  the 
schedule . 

The  remainder  of  this  chapter  discusses  the  implementation  of  the 
prototype  and  alternative  approaches.  The  data  structures  used  by  the 
prototype  are  presented  first.  Sections  are  devoted  to  the  user  inter¬ 
face,  CSNAS  interface,  input  of  program  characteristic  values,  schedule 
development,  and  schedule  modification.  The  chapter  concludes  with  a 
brief  discussion  of  alternative  approaches. 

Data  gt^uptytye? 

Guru's  database  facilities  are  used  to  manage  information  for  de¬ 
fense  acquisition  programs.  Figure  2  illustrates  the  structure  of  the 
database.  The  prototype  uses  a  program  table  to  keep  track  of  acquisi¬ 
tion  programs.  A  set  of  three  tables  is  associated  with  each  program. 


One  table  contains  the  program  characteristic  values.  The  other  two 


tables  (one  for  tasks  and  one  for  links)  contain  schedule  data.  A  sepa¬ 
rate  set  of  working  tables  is  used  to  load  copies  of  program  informa¬ 
tion.  All  data  manipulation  is  performed  using  the  copies  in  the  work¬ 
ing  tables.  Changes  are  saved  from  the  working  tables  back  to  the  ap¬ 
propriate  program  tables.  The  transfer  table  supports  transfer  of  pro¬ 
gram  Information  to  and  from  ASCII  data  files.  All  data  is  stored  in 
tables  as  strings. 

The  program  table  consists  of  two  fields.  The  first  field  (three 
numeric  characters)  contains  the  program  ID  number.  The  second  field 
(20  characters)  contains  the  program  name.  The  program  ID  number  is 
used  to  identify  the  set  of  program  information  tables  associated  with 
the  program  name.  Table  II  shows  a  sample  program  table. 


Table  II.  Program  Table 


TABLES 

NAME 

000 

Default  Schedule 

001 

Program  001 

002 

Demo  2 

003 

Fiber  Optics  Central  Europe 

The  characteristics  table  consists  of  three  fields.  The  first 
field  (30  characters)  contains  program  characteristic  descriptions.  The 
second  field  (20  characters)  contains  program  characteristic  values. 
The  third  field  (15  characters)  identifies  the  source  of  the  value. 
"DEFAULT"  indicates  that  the  user  has  not  confirmed  the  value  associated 
with  the  program  characteristic;  "USER"  indicates  the  user  input  the 
value;  and  "RULE  ..."  indicates  that  the  value  was  created  by  the  rule 


referenced.  The  program  characteristics  table  is  stored  in  a  disk  file. 
The  filename  consists  of  the  letter  "P"  followed  by  the  program  ID  num¬ 
ber  followed  by  the  string  "CHAR.ITB".  For  example,  default  program 
values  are  stored  in  file  "P000CHAR. ITB" .  Table  III  shows  a  sample 
characteristics  table. 

Table  III.  Characteristics  Table 


PROGRAM  CHARACTERISTIC 

VALUE 

SOURCE 

RDTE  DOLLARS 

1 

USER 

PRODUCTION  DOLLARS 

1 

USER 

OTHER  SERVICES 

NONE 

DEFAULT 

MCCR  INVOLVED 

YES 

DEFAULT 

PMRT  PLANNED 

NO 

USER 

TYPE  OF  PROCESSING 

NA 

RULE  NOPMRT 

MAI NT/LOG  SUPPORT 

NA 

RULE  NOPMRT 

ATC  TRAINING 

NA 

RULE  NOPMRT 

PROGRAM  START  DATE 

900101 

USER 

The  task  table  contains  task  information  used  by  CSNAS.  The  first 
field  (five  characters)  contains  the  task  number.  The  second  field 
(five  characters)  contains  the  task  duration  in  workdays.  The  third 
field  (four  characters)  contains  the  group  code.  The  fourth  field 
(three  characters)  contains  the  percentage  completion.  The  fifth  field 
(24  characters)  contains  a  task  description.  The  sixth  field  (12  char¬ 
acters)  contains  the  office  of  primary  responsibility  (OPR).  The  sev¬ 
enth  and  eighth  fields  (one  character  each)  contain  the  user  input  start 
and  user  input  complete  codes  respectively.  The  ninth  through  sixteenth 


fields  (six  characters  each)  contain  the  early  start,  early  complete, 
late  start,  late  complete,  user  start,  user  complete,  baseline  start  and 
baseline  complete  dates  respectively.  Table  IV  shows  a  sample  task 
table . 


Table  IV.  Task  Table 


TASK 

TASK 

GROUP 

PERCENT 

TASK 

NUMBER 

DURATION 

CODE 

COMPLETE 

DESCRIPTION 

OPR 

10 

0 

1 

0 

DRAFT  PMD 

PM  &  PEM  / 

20 

20 

1 

0 

ASSESS  COST 

PM  &  RWPE  / 

30 

23 

1 

0 

FINAL  PMD 

PM  &  PEM  / 

40 

45 

1 

0 

I PR  PREP 

PM 

290 

64 

1 

0 

CONTRACT  AWARD 

RWK  \ 

USER 

INPUT  CODE 

SCHEDULE  DATES 

START 

COMPLETE 

ES 

EC 

LS 

LC 

US 

UC 

BS 

BC 

/  1 

1 

H 

0 

0 

0 

900101  900101 

0 

■9 

/  1 

1 

0 

0 

0 

0 

0 

0 

0 

I  m 

/  1 

1 

0 

0 

0 

0 

0 

0 

0 

0 

1 

1 

0 

0 

0 

0 

0 

0 

0 

■ 

1  1 

1 

0 

0 

0 

0 

0 

0 

0 

ES: 

Early  Start 

EC: 

Early  Complete 

LS: 

Late  Start 

LC: 

Late  Complete 

US: 

User  Start 

UC: 

User  Complete 

BS: 

Baseline  Start 

BC: 

Baseline  Complete 
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Although  the  prototype  does  not  use  all  of  these  fields,  including 
all  the  fields  in  the  task  table  facilitates  importing  data  from  and 
exporting  data  to  CSNAS.  Furthermore,  an  operational  system  may  require 
some  (or  possibly  all)  of  the  fields  not  currently  used.  The  task  table 
is  stored  in  a  disk  file.  The  filename  consists  of  "P" ,  the  program  ID 
number,  and  "TASK.ITB".  For  example,  the  tasks  for  the  default  schedule 
are  stored  in  file  "P000TASK. ITB* . 

The  link  table  contains  two  fields  (five  characters  each)  to  show 
the  relationships  between  tasks.  The  first  field  contains  the  number  of 
a  task  that  precedes  the  task  identified  in  the  second  field.  For  exam¬ 
ple,  the  fact  that  task  10  precedes  task  20  is  established  by  storing  10 
in  the  first  field  and  20  in  the  second  field.  Table  V  shows  a  sample 
link  table. 

Table  V.  Link  Table 


PREDECESSOR 

SUCCESSOR 

10 

20 

20 

30 

20 

40 

90 

290 

A  separate  table  for  links  is  used  for  efficiency  purposes.  Al¬ 
though  many  tasks  have  only  one  predecessor  and  one  successor,  some 
tasks  may  have  many  predecessors  and/or  many  successors.  The  link  table 


is  stored  in  a  disk  file.  The  filename  consists  of  "P",  the  program  ID 
number,  and  "LINK.ITB".  For  example,  the  links  for  the  default  schedule 
are  stored  in  file  "P000LINK. ITB" . 

The  working  tables  are  identical  in  structure  to  the  tables  associ¬ 
ated  with  each  acquisition  program.  The  files  for  the  working  tables 
are  "CURRCHAR.  ITB" ,  "CURRTASK.  ITB" ,  and  "CURRLINK. ITB" .  The  transfer 
table  contains  a  single  field  of  70  characters.  Details  for  using  the 
table  are  described  in  the  section  on  the  CSNAS  interface. 

User  Interface 

A  menu-driven  interface  was  implemented  to  guide  the  user  through 
the  process  of  developing,  modifying,  and  analyzing  schedules.  Prompts 
are  used  to  explain  system  options  and  request  data  input.  Color  is 
used  to  improve  the  appeal  of  the  prototype.  All  menus  contain  a  maxi¬ 
mum  of  six  choices  (including  exit),  and  the  user  selects  an  option  by 
typing  a  single  letter.  Equivalent  operations  (such  as  Show  Data)  in 
different  menus  use  the  same  command.  The  prototype  evaluates  all  in¬ 
puts  and  advises  the  user  of  invalid  selections. 

Menus  and  prompts  were  built  using  Guru's  screen  management  facil¬ 
ity.  This  facility  allows  the  user  to  create  forms  which  consist  of 
boxes  of  text.  Boxes  are  defined  with  screen  position,  background  co¬ 
lor,  foreground  color,  and  special  effects  such  as  borders  and  reverse 
video.  Text  can  be  positioned  anywhere  on  the  screen.  Inputs  can  be 
limited  to  a  specific  number  and  type  of  characters.  For  example,  input 
may  be  limited  to  a  single  alphabetic  character,  four  digits,  or  any 
combination  of  ASCII  characters. 


The  prototype  interfaces  with  CSNAS  through  an  ASCII  data  file. 
This  requires  the  user  to  export  data  to  the  ASCII  file  and  exit  to  the 
operating  system.  Then  CSNAS  is  started,  and  the  ASCII  file  is  loaded 
into  CSNAS  for  schedule  computations,  reports,  plot  generation,  etc.  If 
desired,  the  user  can  save  any  changes  made  by  CSNAS.  The  prototype  can 
import  the  changed  data  for  further  manipulation  such  as  performing 
schedule  analysis.  Although  this  process  is  undesirable  for  an  opera¬ 
tional  system,  it  is  sufficient  to  demonstrate  that  the  system  can  in¬ 
terface  with  other  software  packages  using  data  files. 

The  PC  version  of  CSNAS  uses  a  flat  data  file  which  stores  data  by 
position  in  the  file.  For  example  the  first  five  characters  of  odd 
numbered  lines  contain  the  task  number.  The  next  five  characters  con¬ 
tain  the  duration  in  workdays.  A  full  description  of  the  CSNAS  data 
format  is  available  in  the  CSNAS  User's  Guide  (AFALC,  1987:247-248). 

Guru  provides  facilities  to  import  and  export  data  from  database 
tables  in  six  different  formats  (MDBS,  1987:2:45).  None  of  the  six 
formats  were  sufficient  to  import  and  export  directly  from  the  table  to 
a  CSNAS  data  file.  Thus,  a  transfer  table  is  used  to  store  and  transfer 
data.  Data  to  be  exported  is  extracted  from  the  appropriate  tables  and, 
using  string  operators,  concatenated  together  to  form  lines  that  match 
the  CSNAS  format.  Each  line  created  is  added  to  the  transfer  table. 
The  data  in  the  transfer  table  is  exported  to  a  file  using  Guru's  un¬ 
quoted  ASCII  format.  Data  may  be  imported  for  further  analysis/modific¬ 
ation  by  reversing  the  process.  Data  is  imported  from  the  CSNAS  data 
file  into  the  transfer  table.  Then  data  is  extracted  from  each  line  of 


the  transfer  table  and  stored  in  the  appropriate  working  table.  The 
transfer  table  is  also  used  to  export  a  copy  of  the  program  characteris¬ 
tics  to  an  ASCII  data  file. 


Input  of  Program  Characteristic  Values 

Rules  are  used  prompt  the  user  for  the  values  of  relevant  program 
characteristics.  The  user  is  asked  to  confirm  or  change  values  of  pro¬ 
gram  characteristics  whenever  the  source  of  the  value  is  "DEFAULT".  The 
source  of  the  value  is  changed  to  "USER"  upon  user  acceptance  of  the 
default  or  input  of  a  new  value.  Rules  are  used  to  change  the  values  of 
characteristics  which  are  irrelevant  based  on  user  inputs  for  related 
characteristics.  For  example,  the  existence  of  a  security  classifica¬ 
tion  guide  is  marked  "NA"  with  a  source  of  "RULE  NOCLASS"  when  the  user 
states  that  the  program  is  unclassified. 

The  actual  prompts  for  program  characteristic  values  are  maintained 
in  individual  perform  files.  Perform  files  are  procedural  modules 
which  do  not  require  compilation.  Although  this  increases  the  number  of 
files  used,  the  modularity  facilitates  maintenance  of  the  prompts.  New 
prompts  and  changes  to  existing  prompts  can  be  made  without  affecting 
other  modules.  Figure  3  shows  an  example  prompt  for  a  program  charac¬ 


teristic.  The  user  can  select  a  response  by  entering  the  minimum  number 
of  distinguishing  characters.  The  default  response  for  the  example 
below  is  "INLINE".  Pressing  <RETURN>  accepts  this  choice,  typing  "R" 
selects  "RETROFIT",  and  typing  "B"  selects  "BOTH".  This  minimizes  user 
typing  and  corrects  for  typographical  errors  as  long  as  the  first  char¬ 
acter  is  correct. 
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The  type  of  installation  affects  the  duration  of  developing 
a  cost  estimate.  Equipment  is  installed  during  development 
(inline)  or  after  development  (retrofit).  Equipment  may  be 
installed  both  inline  and  retrofitted. 

TYPE  OF  INSTALLATION:  INLINE 


CHOICES 

INLINE , RETROFIT , BOTH 


Figure  3.  Example  Prompt  for  a  Program  Characteristic  Value 

Schedule  Generation 

The  centerpiece  of  the  prototype  is  a  rule  set  for  generating  a 
schedule  based  upon  program  characteristic  values.  The  flow  of  data 
between  the  working  tables  and  the  rule  sets  is  depicted  in  Figure  4. 
Rule  set  "Get  Characteristics"  prompts  the  user  for  the  program  charact¬ 
eristic  values  and  stores  the  responses  in  the  working  characteristics 
table.  Rule  set  "Build  Schedule"  uses  the  stored  values  to  determine 
task  applicability,  durations,  and  relationships.  Data  for  applicable 
tasks  is  stored  in  the  working  task  and  link  tables. 

The  "Build  Schedule"  rule  set  builds  the  schedule  from  scratch.  It 
begins  with  the  start  task  and  continues  to  add  relevant  tasks  until  the 
network  is  completed.  The  program  characteristic  values  are  used  to 


determine  if  a  task  is  needed  and  to  calculate  the  duration  of  the 


Casks.  The  rules  make  links  between  the  task  being  added  and  all  of  its 


immediate  predecessors  (tasks  which  must  be  completed  before  the  new 


task  begins) .  Appendix  D  contains  a  listing  of  the  rules  used  for 


schedule  generation. 


Working  Tables 


Characteristics 


Get  Program 
Characteristics 


Tasks 


Build  Schedule 


Links 


Figure  4.  Data  Flow  Between  Working  Tables  and  Rule  Sets 


The  prototype  contains  rules  for  52  tasks.  Up  to  23  of  these  tasks 


may  not  apply  to  (be  included  in)  a  schedule  for  a  specific  program. 


Some  tasks  are  mutually  exclusive.  For  example,  Justification  and  Ap¬ 


proval  Activities  and  Source  Selection  activities  will  never  occur  in 


the  same  network.  Many  tasks  are  included  or  omitted  as  a  set.  For 


example,  five  tasks  are  related  to  Source  Selection.  These  complex 


inter-relationships  make  it  difficult  to  determine  the  exact  number  of 


potential  schedules  which  could  be  generated.  A  conservative  estimate 


is  that  the  prototype  could  generate  up  to  8000  different  networks 
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considering  only  the  presence  or  absence  of  tasks.  More  than  10,000 
different  schedules  could  be  generated  when  taking  Into  account  the 
permutations  created  by  different  task  durations. 

A  perform  module  (Guru  procedural  code)  is  used  by  the  rules  to 
create,  initialize,  and  add  tasks  to  the  task  data  table.  The  rule  then 
modifies  the  task  duration,  description,  and  office  of  primary  responsi¬ 
bility  (OPR).  Task  numbers  start  with  10  increment  by  10.  Thus,  the 
first  task  invoked  is  given  a  task  number  of  10,  the  second  task  is 
given  a  task  number  of  20,  and  so  on. 

The  prototype  creates  the  start  task  and  works  forward  to  the  fin¬ 
ish  task.  New  tasks  are  added  when  all  of  their  predecessors  have  been 
created.  This  process  continues  until  a  complete  schedule  is  generated. 
This  mimics  one  way  that  a  person  might  build  a  schedule.  One  advantage 
of  this  approach  is  that  the  first  task  is  always  10,  the  last  task  is 
always  the  largest  task  number,  and  the  magnitude  of  the  task  number 
gives  an  indication  of  where  the  task  occurs  within  the  topology  of  the 
network. 

The  key  parts  of  a  rule  are  the  premise  clause  (IF  statements)  and 
the  action  clause  (THEN  statements).  When  the  conditions  in  the  premise 
clause  are  true,  Guru  executes  the  statements  in  the  action  clause.  The 
premise  of  rules  for  tasks  which  will  always  occur  are  written  so  that 
the  rule  will  always  fire  (execute  THEN  statements)  at  the  appropriate 
time  during  schedule  development.  The  premise  of  rules  for  tasks  which 
may  not  occur  are  written  so  that  the  rule  will  fire  only  when  the  task 
applies  to  (should  be  included  in)  the  schedule  being  generated.  This 
process  is  best  illustrated  by  considering  a  few  rules  in  the  prototype. 


Figure  5  shows  the  rule  for  the  start  task. 


ASKDONE"  is  a  vari¬ 


able  which  is  always  set  to  true  before  consulting  (invoking)  the  rule 
set  to  generate  a  schedule.  Thus,  the  start  task  will  always  occur. 
Since  all  other  tasks  depend  on  the  start  task  or  one  of  its  successors, 
the  start  task  will  always  be  the  first  task  created.  "PERFORM  ADDTASK" 
calls  the  perform  module  to  create  a  new  task  in  the  current  task  table 
(CURRTASK) 

i  _ 


IF: 

ASKDONE 

THEN: 

PERFORM  ADDTASK 

CURRTASK. DUR  -  "  0" 

CURRTASK. DESCR  -  "DRAFT  PMD 
CURRTASK. OPR  -  "PM  &  PEM 

CURRTASK. US  -  vstart 

CURRTASK. UC  -  vstart 
tdpmd  -  CURRTASK. ID 

11 

Figure  5.  Rule  for  "DRAFT  PMD" 


The  next  three  iines  change  the  duration,  description,  and  OPR  of 
the  task  respectively.  The  next  two  lines  change  the  user  input  start 
date  and  user  input  complete  date  to  the  program  start  date  (vstart) 
input  by  the  user.  Variable  "tdpmd"  in  the  last  line  is  used  to  hold 
the  task  number  for  task  "DRAFT  PMD".  This  assignment  also  tells  the 
other  rules  that  a  task  has  been  created  for  "DRAFT  PMD" . 

Figure  6  shows  the  rule  for  a  task  which  may  not  apply  to  a  sched¬ 
ule  for  a  specific  acquisition  program.  Variable  "vthreat"  contains  the 
value  for  the  program  characteristic  "SYSTEM  THREAT".  If  a  threat  does 
not  exist,  this  rule  will  never  execute,  and  the  "THREAT  INPUT"  task 
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will  not  be  Included  in  the  network.  If  a  threat  does  exist,  the  rule 
will  not  fire  until  variable  "tfpmd"  is  KNOWN  (given  a  value).  Variable 
"tfpmd"  is  used  to  store  the  task  number  for  the  task  "FINAL  PHD". 
Thus,  this  rule  fires  after  the  "FINAL  PMD"  task  has  been  created  only 
if  a  system  threat  exists.  If  the  premise  is  true,  a  new  task  is  creat¬ 
ed  and  given  the  next  task  number.  The  duration,  description,  and  OPR 
are  changed  as  shown,  and  variable  "tthreat"  is  assigned  the  task  number 
for  "THREAT  INPUT". 


IF: 

vthreat  -  "YES"  and  KNOWN (tfpmd) 

THEN: 

PERFORM  ADDTASK 

CURRTASK . DUR  -  "  23" 

CURRTASK . DESCR  -  "THREAT  INPUT 
CURRTASK. OPR  -  "PM  &  FTD 
tthreat  -  CURRTASK. ID 

ATTACH  1  TO  CURRLINK 

CURRLINK. PRED  -  tfpmd 

CURRLINK. SUCC  -  tthreat 

N 

Figure  6.  Rule  for  "THREAT  INPUT" 


The  final  three  lines  create  the  link  between  "THREAT  INPUT"  and 
"FINAL  PMD"  by  adding  a  new  record  to  the  link  table  (CURRLINK)  and 
changing  the  values  of  the  predecessor  and  successor  fields.  Note  that 
this  approach  only  makes  links  to  predecessors  when  the  rule  is  execut¬ 
ed.  The  rule  only  contains  knowledge  about  what  the  task  depends  on. 
It  contains  no  knowledge  about  what  follows  the  task. 

Figure  7  shows  the  rule  for  a  task  which  always  applies  but  depends 
on  a  task  which  may  not  occur.  This  rule  executes  when  both  an  "IPR" 
task  has  been  created,  and  either  a  "THREAT  INPUT"  task  has  been  created 


or  the  system  Is  not  threatened.  An  "IPR"  task  will  always  occur  in  the 
schedule.  The  second  part  of  the  premise  will  always  be  true  because 
"THREAT  INPUT"  will  occur  unless  the  system  is  not  threatened  (vthreat 
O  "YES").  Thus,  the  premise  will  always  be  true  at  some  point  during 
schedule  development.  When  the  premise  is  true,  a  new  task  is  created 
and  added  CURRTASK. 


IF:  KNOWN(tipr)  and 

(KNOWN(tthreat)  or  vthreat  O  "YES") 
THEN:  PERFORM  ADDTASK 

duration  -  140 
IF  vscomp  -  "MAJOR"  THEN 
duration  -  duration  +  20 
END  IF 

IF  vjoint  -  "NONE"  THEN 
duration  -  duration  -  30 
END  IF 

CURRTASK. DUR  -  TOSTR(duration, 5 ,0) 
CURRTASK. DESCR  -  -DRAFT  SPEC 
CURRTASK. OPR  -  "PM  &  RWE 
tdspec  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tipr 
CURRLINK . SUCC  -  tdspec 
IF  KNOWN (t threat)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tthreat 
CURRLINK. SUCC  -  tdspec 
END  IF 


Figure  7.  Rule  for  "DRAFT  SPEC' 


This  rule  also  demonstrates  the  use  of  program  characteristic  val¬ 
ues  to  calculate  task  duration  in  the  action  clause.  The  default  dura¬ 
tion  is  140  days.  If  the  system  complexity  is  major  (vscomp  - 
"MAJOR"),  then  the  duration  is  increased  by  20  days.  If  the  program 


does  not  involve  other  services  (vjoint  -  "NONE"),  then  the  duration  is 
reduced  by  30  days.  "TOSTR(duration, 5 ,0) "  converts  the  duration  from  a 
number  to  a  string  of  length  five  with  zero  decimals.  The  duration, 
description,  and  OPR  are  changed  as  shown.  Variable  "tdspec"  is  given 
its  appropriate  value,  and  a  link  is  made  between  "IPR"  and  "DRAFT 
SPEC".  Finally,  if  "THREAT  INPUT"  does  exist,  a  link  will  be  made  be¬ 
tween  "THREAT  INPUT"  and  "DRAFT  SPEC". 

The  premise  of  rules  which  depend  on  one  or  more  tasks  which  may 
not  exist  can  become  fairly  complex.  Figure  8  shows  the  most  complex 
rule  in  the  prototype.  The  first  clause  of  the  premise  tests  whether 
"DRAFT  CRISP*  has  occurred  or  Mission  Critical  Computer  Resources  are 
not  used  or  Program  Management  Responsibility  Transfer  will  not  occur. 
The  second  clause  tests  if  "AP  APPROVAL"  (acquisition  plan  approval)  has 
occurred  or  program  work  is  in  the  scope  of  a  current  contract.  The 
third  clause  tests  if  "DRAFT  RFP"  has  occurred,  or  both  a  draft  RFP  will 
not  be  used  and  "SOURCES  SOUGHT  SYNOP"  has  occurred,  or  both  a  sources 
sought  synopsis  is  not  needed  and  "DRAFT  SOW"  has  occurred.  The  final 
clause  of  the  premise  tests  if  "WBS  APPROVAL"  (approval  of  the  work 
breakdown  structure)  has  occurred  or  the  dollar  value  of  the  contract  is 
low  enough  that  WBS  approval  is  not  required. 

Each  condition  within  a  clause  is  mutually  exclusive  (if  one  part 
of  the  clause  is  false,  then  the  other  is  true).  Thus,  this  rule  will 
always  fire  after  those  tasks  which  will  occur  have  been  created.  When 
the  rule  fires,  a  new  task  is  created  and  added  to  CURRTASK.  The  dura¬ 
tion,  description  and  OPR  are  changed.  The  task  number  is  assigned  to 
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tfsow".  The  remainder  of  the  action  clause  creates  links  to  tasks 


IF:  (KNOWN(tdcrisp)  or  vmccr  O  "YES"  or  vpmrt  O  "YES") 

and  (KNOWN(tapa)  or  vinscope  -  "YES")  and 
KNOWN(tdilsp)  and 

(KNOWN(tdrfp)  or  (vdrfpn  O  "YES"  and 
(KNOWN(tsss)  or  (vsssn  O  "YES"and 
KNOWN (tdsow)))))  and 

(KNOWN (twbsa)  or  (vrdte  <-  2  and  vprod  <-2)) 

THEN:  PERFORM  ADDTASK 

CURRTASK . DUR  -  "  40" 

CURRTASK . DESCR  -  "FINAL  SOW 
CURRTASK. OPR  -  "PM  &  RWE 
tfsow  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tdilsp 
CURRLINK. SUCC  -  tfsow 
IF  KNOWN(tdcrisp)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdcrlsp 
CURRLINK. SUCC  -  tfsow 
ENDIF 

IF  KNOWN(tapa)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tapa 
CURRLINK. SUCC  -  tfsow 
ENDIF 

IF  KNOWN (tdrfp)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdrfp 
CURRLINK. SUCC  -  tfsow 
ELSE 

IF  KNOWN(tsss)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tsss 
CURRLINK. SUCC  -  tfsow 
ELSE 

ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdsow 
CURRLINK. SUCC  -  tfsow 
ENDIF 
ENDIF 

IF  KNOWN (twbsa)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  twbsa 
CURRLINK. SUCC  -  tfsow 
ENDIF 


Figure  8.  Rule  for  "FINAL  SOW" 
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which  are  known  to  exist.  Connections  are  made  to  "DRAFT  CRISP",  "AP  _ 
APPROVAL",  "DRAFT  RFP"  and  "WBS  APPROVAL"  if  they  exist.  If  "DRAFT  RFP" 
does  not  exist,  a  link  is  made  to  "SOURCES  SOUGHT  SYNOP"  if  it  exists. 
If  both  "DRAFT  RFP"  and  "SOURCES  SOUGHT  SYNOP"  do  not  exist,  a  link  is 
made  to  "DRAFT  SOW".  The  third  clause  is  so  complex  because  "DRAFT  SOW" 
always  occurs  and  is  a  predecessor  to  a  task  which  does  not  normally 
occur.  The  third  clause  is  necessary  to  insure  that  a  link  will  always 
be  made  to  "DRAFT  SOW"  even  if  both  "SOURCES  SOUGHT  SYNOP"  and  "DRAFT 
RFP"  do  not  occur. 

Each  task  in  the  network  is  handled  by  a  single  rule.  The  premise 
of  the  rule  is  written  to  create  the  task  at  the  appropriate  point  in 
schedule  development.  Tasks  which  always  exist  have  premises  which  are 
always  true  at  the  appropriate  point  in  schedule  development.  Tasks 
which  may  not  occur  have  premises  that  are  true  only  when  program  char¬ 
acteristic  values  indicate  that  the  task  should  be  included  in  the  net¬ 
work.  The  actions  of  the  rule  create  the  task,  calculate  task  duration 
using  program  characteristic  values,  and  make  links  to  all  immediate 
predecessors . 

This  process  makes  each  rule  relatively  independent  of  the  other 
rules.  The  only  dependencies  are  those  created  by  task  links.  Thus, 
all  task  data  (duration,  description,  OPR,  schedule  dates,  etc.)  can  be 
changed  within  the  action  clause  of  a  rule  without  affecting  other 
rules.  When  adding  or  deleting  rules,  the  developer/maintainer  need 
only  concern  himself  with  the  task  involved  and  its  immediate  predecess¬ 
ors  and  successors.  If  a  task  is  deleted  (the  rule  for  the  task  removed 
from  the  rule  set),  the  developer/maintainer  must  insure  that  its  imraed- 
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late  predecessors  still  have  successors  and  its  immediate  successors 
still  have  predecessors .  When  adding  tasks  (creating  a  new  rule),  the 
developer/maintainer  must  create  the  premise  so  that  the  task  will  be 
created  at  the  appropriate  point  in  the  network.  The  action  must  create 
the  task,  calculate  task  duration,  and  make  links  to  preceding  tasks. 
Succeeding  tasks  must  be  modified  to  insure  that  proper  links  are  made 
to  the  new  task. 

The  rule-base  for  generating  the  schedule  was  built  using  the  pro¬ 
cess  just  described.  Rules  were  written  based  on  information  gathered 
during  the  knowledge  acquisition  phase.  The  Phase  I  network  was  used 
only  to  determine  links  and  durations  for  tasks  which  were  not  covered 
in  the  knowledge  engineering  phase.  The  topology  of  the  Phase  I  network 
was  not  used  as  a  guide  for  rule  development.  Indeed,  the  actual  topol¬ 
ogy  of  the  generated  schedules  were  unknown  until  CSNAS  plots  were  gen¬ 
erated. 

Based  on  this  thesis,  a  rule  set  to  generate  a  network  schedule 
containing  fifty  tasks  can  be  built  in  one  or  two  months.  This  assumes 
that  the  developer  works  full-time  on  the  project  and  has  full  coopera¬ 
tion  from  (access  to)  the  individuals  who  will  provide  the  knowledge  for 
the  system.  The  rule  set  will  be  a  prototype  which  must  be  refined  and 
maintained.  The  time  to  reach  maturity  for  the  rule  set  is  unknown. 

Schedule  Modification 

A  rudimentary  facility  for  modifying  an  existing  schedule  by  chang¬ 
ing  program  characteristic  values  was  implemented.  The  user  can  create 
a  new  schedule  (or  simply  modify  the  existing  one)  by  changing  program 
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characteristic  values.  This  lets  the  user  generate  multiple  versions  of 
a  program  schedule  by  changing  key  program  characteristic  values.  Thus, 
alternative  approaches  can  be  evaluated  by  generating  a  schedule  for 
each  alternative.  For  example,  schedules  might  be  generated  for  both 
sole  source  and  competitive  acquisitions.  The  two  schedules  could  then 
be  compared  to  see  which  is  better  given  the  risk  involved  and  other 
appropriate  factors. 

If  the  user  wants  a  new  schedule,  the  system  makes  a  copy  of  the 
schedule  to  be  modified.  Otherwise,  the  system  modifies  the  existing 
schedule  when  the  user  saves  the  changes.  Guru's  browse  facility  is 
used  to  allow  the  user  to  review  all  program  characteristic  values  and 
make  changes  as  desired.  When  completed,  the  user  can  save  the  changes 
or  ask  the  system  to  generate  a  new  schedule  based  on  the  new  program 
characteristic  values.  A  more  elaborate  interface  similar  to  that  used 
to  input  program  characteristic  values  would  be  developed  for  the  opera¬ 
tional  system. 

Alternative  Approaches 

The  approach  described  for  generating  schedules  is  one  of  four 
considered.  The  prototype  generates  schedules  forward  from  the  start 
task  as  described  above.  Schedules  could  also  be  generated  working 
backward  from  the  finish  task,  creating  tasks  independently,  or  using 
frames . 

The  same  approach  used  to  work  forward  from  the  start  task  could  be 
used  to  work  backward  from  the  finish  task.  The  finish  task  would  be 


created  first.  Then  a  task  would  be  created  only  if  it  applied  and  the 
task  which  follows  it  had  already  been  completed.  For  example,  "CON- 


TRACT  AWARD"  is  the  finish  task  and  depends  on  "SOURCE  SELECTION". 
Thus,  "CONTRACT  AWARD"  would  be  created  first.  "SOURCE  SELECTION"  would 
be  created  after  "CONTRACT  AWARD",  and  a  link  made  between  the  two. 


Note  that  this  case  requires  the  rule  to  know  what  tasks  are  dependent 
on  the  task  created.  The  rule  would  contain  no  knowledge  about  what 
tasks  precede  the  new  task.  The  numbering  would  be  backwards,  but  num¬ 
bering  is  irrelevant  to  schedule  computation  and  could  be  easily  changed 
if  desired.  This  approach  merely  takes  a  different  viewpoint  from  that 
used  for  the  demonstration  prototype. 

A  schedule  could  be  built  by  generating  tasks  independently.  Tasks 
which  always  occur  would  be  created  automatically.  Tasks  which  depend 
on  program  characteristic  values  would  be  created  (if  they  apply)  re¬ 
gardless  of  what  other  tasks  exist.  The  rules  for  these  tasks  would  not 
contain  any  link  information.  Once  all  the  tasks  were  created,  a  separ¬ 
ate  rule  base  could  create  links  between  the  tasks  that  exist.  This 
approach  would  separate  link  information  entirely  from  task  creation. 
Thus,  maintenance,  addition,  and  deletion  of  rules  could  become  more 
difficult  than  using  the  modular  approach  described. 

A  frame-based  system  could  be  used  to  generate  schedules.  Each 
task  could  be  represented  as  an  instance  of  a  generic  task  frame.  The 
frame  could  contain  slots  for  all  of  the  data  maintained  in  the  tables 
of  the  rule-based  system.  Methods  could  be  written  to  determine  if  the 
task  applied,  create  the  task,  calculate  the  task  duration,  and  make 
links  to  other  tasks.  A  frame-based  system  would  further  enhance  the 
modularity  of  the  tasks.  However,  PC-based  frame  tools  were  not  readily 
available,  and  rules  are  easier  to  encode. 
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The  prototype  accepts  more  than  six  trillion  possible  combinations 
of  program  characteristic  values  and  can  generate  thousands  of  sched¬ 
ules.  Testing  of  all  possible  inputs  is  impossible.  Thus,  the  system 
was  evaluated  in  two  ways.  First,  tests  were  run  to  increase  the  con¬ 
fidence  that  the  system  would  generate  a  schedule  regardless  of  the 
combination  of  program  characteristic  values.  Then  the  prototype  was 
demonstrated  to  potential  developers  and  users  of  an  operational  system. 
Each  person  who  witnessed  a  demonstration  was  asked  to  evaluate  the 
prototype  by  answering  a  questionnaire. 

Prototype  Testing 

The  system  was  implemented  using  modular  components.  Each  compon¬ 
ent/collection  of  components  was  tested  as  it  was  built.  The  user  in¬ 
terface  was  tested  (using  stubs  for  each  option)  by  selecting  every 
option  available.  The  CSNAS  interface  was  tested  by  exporting  and  im¬ 
porting  data  files.  Exported  data  files  were  loaded  into  CSNAS  and 
tested  for  compatibility. 

The  rule  set  for  input  of  program  characteristic  values  was  tested 
by  using  it  to  prompt  for  program  characteristic  values  and  reviewing 
the  stored  data  to  see  that  it  matched  the  inputs.  Testing  the  rule  set 
for  schedule  generation  proved  to  be  more  difficult.  Thirteen  program 
characteristics  (containing  49  choices)  directly  affect  the  existence 
of  23  tasks.  The  remaining  program  characteristics  affect  the  duration 


of  tasks.  Initial  efforts  were  spent  on  generating  a  schedule  based  on 
default  program  characteristic  values.  Then,  program  characteristic 
values  which  affected  task  applicability  were  changed  and  new  schedules 
generated.  Finally,  random  input  of  program  characteristic  values  was 
used. 


Approximately  twenty  schedules  were  generated  using  different  pro¬ 
gram  characteristic  values.  When  the  prototype  failed  to  generate  a 
complete  schedule,  Guru's  trace  facility  was  used  to  locate  the  problem. 
Proper  schedules  were  not  generated  for  two  reasons.  Some  tasks  were 
incorrectly  omitted  due  to  an  incorrect  premise  statement  for  the  rule. 
These  errors  were  corrected  by  modifying  the  premise.  Some  tasks  were 
missing  a  predecessor  and/or  a  successor.  These  errors  were  corrected 
by  modifying  the  actions  of  appropriate  rules  to  insure  that  links  were 
established.  Most  problems  were  located  and  fixed  within  an  hour. 

The  rule  set  for  schedule  generation  was  also  evaluated  by  manually 
reviewing  each  rule.  Rules  for  tasks  that  always  occur  were  reviewed  to 
insure  that  their  premises  were  always  true  at  the  proper  point  in 
schedule  development.  Rules  for  tasks  that  may  not  occur  were  reviewed 
to  insure  that  they  would  execute  only  when  the  task  should  be  included 
in  the  network.  Finally,  cross-checks  were  made  between  rules  to  insure 
that  proper  links  would  be  made  to  create  a  complete  network  regardless 
of  which  tasks  were  used. 

Approximately  ten  more  networks  were  generated  after  evaluating  the 
rules.  Most  of  these  networks  were  generated  using  program  characteris¬ 
tic  values  provided  by  potential  users  during  demonstrations  of  the 
system.  Schedule  length  for  all  test  runs  and  demonstrations  ranged 
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from  18  months  to  34  months.  Schedules  were  generated  by  the  prototype 
In  less  than  15  minutes. 

User  Evaluation 

The  prototype  was  demonstrated  to  18  people.  Schedules  were  gener¬ 
ated,  modified,  and  exported  to  CSNAS  to  demonstrate  system  operation. 
Plots  of  five  schedules  generated  by  the  system  were  shown  to  the  evalu¬ 
ators  following  system  operation.  Everyone  was  asked  to  complete  an 
evaluation  questionnaire  (see  Appendix  E)  after  the  demonstration  was 
completed.  Figure  9  summarizes  the  responses  to  the  first  four  ques¬ 
tions  . 
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Figure  9.  Summary  of  Responses  to  Primary  Criteria 


Evaluations  were  completed  by  people  from  the  Aeronautical  Systems 
Division  (ASD) ,  the  Air  Force  Acquisitions  Logistics  Command  (AFALC) , 
and  The  Applied  Science  Corporation,  Incorporated  (TASC) .  TASC  provides 
scheduling  support  to  ASD.  Sixteen  of  the  eighteen  evaluators  (88  per¬ 
cent)  had  used  network  scheduling  more  than  three  times,  had  used  autom¬ 
ated  project  management  tools  (primarily  CSNAS),  and  had  used  model 
networks.  All  eighteen  (100  percent)  believe  that  network  scheduling 
has  merit.  The  prototype  received  no  negative  comments.  Table  VI 
cross -tabulates  questions  1  and  4. 


Table  VI.  Cross -tabulation  of  Concept  and  Improvement 


The  prototype  accepts  more  than  six  trillion  possible  combinations 
of  program  characteristic  values  and  can  generate  thousands  of  sched¬ 
ules.  The  prototype  was  tested  as  each  component/group  of  components 
was  implemented.  It  generates  tailored  schedules  in  less  than  15  min- 


utes.  Evaluations  by  eighteen  people  with  experience  in  scheduling  and 
the  use  of  model  networks  contained  no  negative  comments. 
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j_  Conclusions  and  Recommendations 


Overview 

The  prototype  successfully  demonstrates  the  feasibility  of  building 
an  Intelligent  Scheduling  Assistant  (ISA).  The  prototype  was  demonstra¬ 
ted  to  people  from  the  Aeronautical  Systems  Division  (ASD) ,  the  Air 
Force  Acquisitions  Logistics  Command  (AFALC) ,  and  The  Applied  Science 
Corporation,  Incorporated  (TASC) .  The  demonstrations  led  to  presenta¬ 
tion  of  the  concept  at  the  ASD/Industry  Scheduling  Workshop.  AFALC 
plans  to  use  the  concept  for  CSNAS  acquisitions  logistics  model  networks 
(Appendix  F) . 

Conclusions 

The  prototype  successfully  demonstrates  the  feasibility  of  building 
ISA.  User  evaluations  (Figure  9,  Chapter  VII)  were  consistently  favor¬ 
able.  Ninety- five  percent  of  the  evaluators  recommended  development  of 
an  operational  system  or  further  research.  Although  the  prototype's 
user  Interface  was  limited  to  menus  and  a  few  verbose  prompts,  ninety  - 
five  percent  of  the  evaluators  rated  the  potential  for  user-friendly 
operation  as  good  to  excellent.  Sixty-six  percent  rated  the  quality  of 
schedules  generated  by  the  prototype  as  reasonable.  Ninety- five  percent 
rated  the  prototype  as  an  improvement  to  model  networks. 

The  lack  of  a  consensus  on  the  quality  of  schedules  generated  by 
the  prototype  Is  derived  from  two  factors.  First,  most  of  the  people 
who  evaluated  the  system  did  not  examine  the  schedules  closely.  Second, 
schedule  quality  is  difficult  to  quantify  However,  schedules  generated 


are  meant  to  be  recommendations  which  must  be  reviewed  and  approved  by 
members  of  the  program  management  team.  Therefore,  the  absence  of  nega¬ 
tive  evaluations  is  significant  considering  the  limited  knowledge  of  the 
prototype  and  the  Intended  use  of  the  results. 

Cross- tabulation  of  concept  and  improvement  (Table  VI,  Chapter  VII) 
shows  strong  support  for  both.  More  than  sixty  percent  of  the  evalua¬ 
tors  recommended  development  of  an  operational  system  and  agreed  that 
the  prototype  was  much  better  than  existing  model  networks. 

The  concept  is  translatable  to  other  network  schedules  using  the 
procedures  outlined  in  this  thesis.  The  first  step  is  to  identify  all 
tasks  which  may  be  included  in  a  given  schedule.  Each  task  Is  analyzed 
to  determine  when  it  applies,  how  durations  are  estimated,  and  what 
relationships  exist.  A  single  rule  can  be  created  to  handle  each  task 
The  premise  of  the  rule  is  written  so  that  the  task  Is  created  at  the 
appropriate  time  during  schedule  development.  The  actions  of  the  rule 
compute  task  durations  and  establish  links  to  Immediate  predecessors 
This  process  can  be  used  to  generate  schedules  without  prior  knowledge 
of  the  final  network  topology.  Furthermore,  only  the  predecessors  of 
tasks  need  to  be  defined. 

Schedule  generators  would  be  easy  to  build  for  the  construction 
Industry  where  tasks,  durations,  and  relationships  are  well  defined 
The  quality  of  the  generated  schedules  would  probably  be  very  high  under 
such  circumstances.  Schedule  generators  can  be  built  for  other  model 
networks  and  where  no  previous  work  has  been  done  to  generate  schedules 
The  time  required  to  build  the  initial  prototype  would  range  from  one  to 
two  months  for  a  network  with  fifty  tasks. 


Interfaces  cen  be  written  to  export  schedule  data  to  other  software 
programs.  The  same  technique  used  to  create  the  CSNAS  data  file  can  be 
used  to  export  data  In  an  appropriate  format  for  database  management 
systems,  other  project  management  tools,  or  other  software  program  which 
allow  data  Interchange. 

Schedules  generated  using  this  approach  are  only  as  good  as  the 
knowledge  contained  In  the  system.  All  generated  schedules  should  re¬ 
main  subject  to  review  by  members  of  the  program  management  team.  The 
knowledge  In  the  system  must  be  continually  reviewed  and  refined.  The 
time  to  reach  maturity  Is  unknown. 

The  prototype  has  generated  a  lot  of  Interest  In  the  ISA  concept. 
It  was  demonstrated  to  AFALC  and  the  AI  group  of  the  Air  Force  Logistics 
Command  (AFLC)  Based  on  the  demonstration,  AFALC  plans  to  apply  the 
concept  to  CSNAS  model  networks  for  acquisition  logistics.  AFLC  Is 
supporting  the  project  with  training  and  Ml  (a  knowledge -engineering 
language  developed  by  Teknowledge ) .  The  concept  was  presented  at  the 
ASD/Industry  Scheduling  Workshop  held  16-19  February  1988  In  Los  Angel¬ 
es.  California  and  will  be  presented  to  TASC  In  March  1988 


Recommendations  for  Future  Research 

The  prototype  was  designed  to  demonstrate  the  feasibility  of  gener¬ 
ating  schedules  using  a  knowledge  based  approach  However,  schedule 
generation  Is  only  one  part  of  the  scheduling  problem  A  significant 
amount  of  effort  Is  needed  to  maintain  schedules  Thus,  methods  for 
modifying  s<hedules  by  adding,  deleting,  or  modifying  'asks  are  essen 
tlal  Analysis  of  schedules  Is  another  key  element  to  successful  use  of 
network  schedules  Thus  research  Into  resolving  schedule  conflicts 


*  ‘  i  \r 


**  ■) 


*  F»rF* 


k*  *v 


using  knowledge -based  techniques  Is  needed.  Adding  lines  of  reasoning 
to  the  current  system  would  be  valuable  to  people  who  review  schedules 
generated  by  the  prototype.  Finally,  automated  procedures  for  generat¬ 
ing  rules  for  ISA  would  be  beneficial. 

Modifying  Tasks. 

Users  will  quickly  become  disenchanted  with  any  computer  program 
which  does  not  allow  them  to  easily  modify  schedules  which  are  generat¬ 
ed.  Methods  for  adding,  deleting,  or  modifying  tasks  in  the  schedule 
are  essential  to  successful  implementation  of  an  operational  ISA.  Al¬ 
though  such  changes  can  be  made  using  CSNAS  or  other  project  management 
tools,  this  is  not  an  acceptable  solution  in  the  long  term.  The  remain¬ 
der  of  this  section  describes  the  kind  of  Interface  needed  to  facilitate 
schedule  modification. 

The  user  should  be  allowed  to  add  any  task  which  Is  deemed  relevant 
to  his  program.  These  may  be  tasks  that  should  ultimately  be  added  to 
the  rule  base  for  schedule  generation,  or  they  may  be  tasks  that  are 
peculiar  to  the  program  in  question.  ISA  should  prompt  the  user  for  all 
information  needed  to  add  the  task  without  requiring  the  user  to  concern 
himself  with  the  details  of  making  the  changes.  For  example,  ISA  should 
automatically  assign  a  task  number  and  prompt  the  user  for  a  descrip¬ 
tion,  duration,  and  office  of  primary  responsibility  (OPR).  ISA  should 
ask  the  user  which  tasks  must  occur  before  the  task  can  begin  and  which 
tasks  cannot  be  done  before  the  task  ends.  ISA  should  handle  the  mecha¬ 
nics  of  creating  the  proper  links.  The  user  should  also  be  allowed  to 
Input  group  codes  and  schedule  dates  as  desired. 


The  user  should  be  allowed  to  delete  tasks  which  are  deemed  irrele¬ 


vant  to  the  program.  The  rule  base  for  schedule  generation  may  require 
modification  to  account  for  the  cause  of  the  deletion,  or  the  deletion 
might  be  peculiar  to  the  program.  ISA  should  analyze  links  to  previous 
tasks  and  advise  the  user  on  how  tasks  should  be  reordered.  For  exam¬ 
ple,  if  "NSR"  is  deleted,  ISA  should  recommend  that  "IPR  PREP"  should 
follow  "ASSESS  COSTS".  ISA  would  make  the  link  only  if  the  user  con¬ 
firms  the  proposed  modification.  Otherwise,  ISA  should  prompt  the  user 
for  desired  links  until  the  network  is  complete. 

The  user  should  be  able  to  modify  task  data  such  as  description, 
duration,  and  schedule  dates.  The  user  should  also  be  able  to  restruc¬ 
ture  the  network.  The  system  should  prompt  the  user  for  the  task  to  be 
modified  or  moved.  When  moving  tasks,  the  system  should  recommend  ap¬ 
propriate  changes  in  links  to  the  user.  For  example,  if  the  user  wanted 
to  show  a  task  was  complete  although  the  predecessors  to  the  task  were 
not  complete,  the  system  should  help  the  user  decide  how  to  restructure 
the  network.  This  would  insulate  the  user  from  the  details  for  moving 
tasks . 

Analyzing  Schedules . 

System  requirements  include  computation  of  schedule  timing  and 
resolution  of  conflicts.  Schedule  timing  is  currently  computed  using 
CSNAS.  The  ability  to  compute  schedule  timing  without  exiting  the  sys¬ 
tem  is  a  needed  improvement.  An  ability  to  recommend  alternatives  to 
resolve  schedule  conflicts  would  dramatically  increase  the  usefulness  of 
the  system.  The  remainder  of  this  section  describes  possible  approaches 
to  providing  these  requirements. 


Schedule  timing  could  be  computed  within  the  system  by  creating  a 
direct  Interface  to  CSNAS  or  developing  Internal  algorithms.  The  first 
approach  would  require  software  which  executes  a  sequence  of  keystrokes 
to  load  and  run  CSNAS.  A  file  containing  the  keystrokes  could  be  gener¬ 
ated  and  Invoked  by  the  system.  This  approach  would  avoid  re-lnventlng 
the  wheel  for  schedule  computation.  The  second  approach  would  use  pro¬ 
gramming  languages,  databases,  or  spreadsheets  to  compute  schedule  tim¬ 
ing. 

Alternatives  for  resolving  schedule  conflicts  could  be  generated 
using  a  rule  set.  Consider  the  case  where  the  schedule  falls  to  meet 
its  target  date  for  completion.  The  system  could  examine  the  network  to 
determine  which  tasks  lie  on  the  critical  path.  Rules  could  be  used  to 
generate  recommendations  for  reducing  the  schedule.  The  recommendation 
would  be  accompanied  by  an  explanation  which  Included  an  assessment  of 
the  risk  to  the  program  if  the  change  is  made.  The  change  would  be  made 
only  upon  user  confirmation. 

Providing  Reasoning. 

A  record  of  the  lines  of  reasoning  used  to  generate  a  schedule 
would  be  useful  to  people  who  review  the  schedule.  The  reviewer  could 
refer  to  the  line  of  reasoning  whenever  he  does  not  understand  why  a 
task  was  Included  (or  omitted),  how  a  duration  was  estimated,  or  how 
relationships  were  established.  If  the  reviewer  disagreed  with  the  line 
of  reasoning,  then  he  would  contact  the  person  responsible  for  the 
schedule  to  recommend  changes . 

Lines  of  reasoning  could  be  maintained  in  a  database  F.ach  rule 
could  be  modified  to  add  text  descriptions  of  why  the  task  applies  and 
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how  the  duration  was  calculated  to  the  database.  Text  descriptions  of 
why  tasks  are  not  in  the  network  could  also  be  added  to  the  database. 
The  lines  of  reasoning  could  then  be  exported  along  with  the  CSNAS  data 
file  and  program  characteristic  values. 

Automating  Rule  Cenemlgn. 

The  rules  contained  in  the  Intelligent  Scheduling  Assistant  are 
fairly  simple  to  construct.  Automating  rule  generation  would  facilitate 
the  development  of  rule  sets  for  other  model  networks.  The  system  could 
prompt  the  user  for  all  possible  tasks  and  knowledge  needed  to  decide 
the  applicability,  duration,  and  links  for  each  task.  The  system  could 
use  this  knowledge  to  generate  rules  for  schedule  development. 

Summary 

This  thesis  has  successfully  demonstrated  the  feasibility  of  build¬ 
ing  an  Intelligent  Scheduling  Assistant.  It  has  generated  interest  In 
using  knowledge -based  techniques  to  Improve  scheduling  efforts  In  ASD 
and  AFALC.  The  concepts  developed  In  this  thesis  are  directly  translat¬ 
able  to  other  network  schedules.  This  thesis  has  spawned  Ideas  for  for 
further  research  Into  using  artificial  Intelligence  to  improve  schedule 


development  and  maintenance. 


Appendix  Ai.  Problem 


This  appendix  contains  the  results  of  the  problem  assessment  inter¬ 
views.  Interviews  were  conducted  Informally  using  a  problem  assessment 
questionnaire  developed  by  Teknowledge,  Inc.  (an  International  knowledge 
engineering  company).  Each  numbered  item  represents  an  area  of  focus. 
Under  each  area  is  an  approximation  of  the  question  asked.  Suggested 
responses  (if  given)  are  contained  in  parentheses.  Actual  responses  are 
preceded  by  an  "** ,  and  the  number  of  individuals  offering  the  response 
as  listed  at  the  right  margin. 

Problem  assessment  interviews  were  directed  toward  the  Phase  I 
network.  People  who  had  not  used  the  network  were  asked  to  consider  how 
they  would  use  the  network.  Some  people  offered  multiple  responses  for 
specific  questions  and  some  declined  to  respond  to  specific  questions. 
All  references  to  "program”  mean  defense  acquisition  program. 


1.  Problem  Definition 


What  are  the  problems  associated  with  model  networks/network 
scheduling? 


*  Time-consuming 

*  Lack  of  acceptance 

*  Phase  I  network  requires  drastic  tailoring 

*  Every  program  is  unique 

*  Lack  of  resources 

*  Managing  schedule  instead  of  program 

*  No  one  person  knows  everything 

*  Lack  of  priority/motivation 

*  Political  decisions 

*  Scheduling  guide  lacks  sufficient  information 

*  Lack  of  experience 

*  Too  many  regulations 

*  PM  doesn't  know  organl rat  tonal  commitment 

*  Changes  occur 


6 

5 

5 

4 

4 

3 

3 

2 

2 

2 

2 

1 

1 

1 


How  do  scheduling  problems  impact  the  organization? 


*  Inefficient  management  6 

*  Time-consuming  to  coordinate  3 

*  Time-consuming  to  research  regulations  3 

*  Workload- intensive  2 

*  Minimal  impact  1 


What  benefits  would  a  solution  to  the  problems  have  (save  money, 
save  time,  improve  productivity)? 


*  Improve  productivity  9 

*  Save  time  4 

*  Improve  logical  consistency  of  schedules  2 

*  Improve  management  2 

*  Help  define  needs  1 

*  Weed  out  non-players  1 

*  Lessons  learned  1 


Current  Practice 


What  are  the  current  procedures  used  to  tailor  the  Phase  I  network 
or  develop  schedules? 


* 

Review/identify  task  applicability 

13 

* 

Coordinate  with  program  management  team 

12 

* 

Review/develop  estimated  task  durations 

12 

* 

Get  copy  of  network 

9 

* 

Review/develop  network  logic 

9 

* 

Modify/maintain  schedule 

6 

* 

Review/develop  OPR 

4 

* 

Learn  about  program  characteristics 

3 

* 

Program  already  in  progress 

2 

* 

Select  most  important  tasks 

2 

* 

Schedule  in  tiers 

2 

* 

Determine  fixed  dates 

1 

* 

Resolve  conflicts 

1 

* 

See  if  goal  fits  network 

1 

* 

Tend  to  add  activities  more  than  delete  activities 

1 

* 

Hire  contractor 

1 

* 

Reviewed  by  corporate  review  group 

1 

What 

expertise  is  needed  to  tailor/generate  schedules? 

* 

Functional  area  knowledge 

15 

* 

Program  experience 

3 

* 

Scheduling 

l 

Where  is  the  expertise  (people,  regulations)? 


*  People  (functional,  PM)  15 

*  Regulations,  policy  letters,  operating  instructions  11 

How  long  does  it  take  a  skilled  scheduler  to  develop  a  top-level 
schedule? 


* 

One  week 

4 

* 

Hours  (days  to  coordinate) 

2 

* 

Two  to  three  weeks 

2 

* 

One  month 

2 

* 

Two  days 

1 

What  is  the  difference  in  performance  between  skilled  schedulers 

and 

average  schedulers? 

* 

Skilled  is  better  by  magnitude  in  time  and  quality 

14 

How 

do  failures  occur? 

* 

Omissions 

6 

* 

Lack  of  experience 

5 

* 

Unrealistic  expectations 

4 

* 

Poor  decisions/assumptions 

3 

* 

Misconceptions 

3 

* 

Lack  of  coordination 

3 

* 

Quit  due  to  frustration 

2 

* 

Radical  differences  between  Phase  I  network  and  program 

1 

* 

Lack  of  support 

1 

* 

Disagreements 

1 

* 

Failure  to  schedule  at  all 

1 

How 

often  do  failures  occur? 

* 

All  the  time 

5 

* 

Occasionally 

2 

What 

are  the  costs  associated  with  failure? 

* 

Increased  costs,  schedule  delays 

8 

* 

Major  Impact 

6 

* 

Kill  program 

2 

* 

Can't  assess  program  status 

1 

How 

should  a  knowledge -based  system  generate  schedules? 

* 

Same  approach  as  currently  used 

8 

* 

Based  on  real  data 

1 

* 

Larger  view  of  program 

1 

How  does  information  flow  in  the  organization  (any  bottlenecks)? 


* 

Good 

6 

★ 

Bottlenecks 

3 

* 

Problems  getting  data  at  start 

1 

* 

Poor 

1 

3.  Problem  Characterization 


What  is  the  goal  of  the  solution  (generate  satisfactory,  optimal, 
or  multiple  schedules)? 


Generate  satisfactory  schedules 
Generate  optimal  schedules 
Generate  multiple  schedules 
No  satisfactory  schedules 


10 

5 

3 

1 


Are  schedules  selected  from  pre-defined  solutions  or  constructed 
without  knowledge  of  the  final  solution? 


Select  from  pre-defined  solutions 
Construct 

Durations  pre-defined 
Precedence  unknown 


11 

3 

1 

1 


How  many  potential  solutions  are  there  (tens,  hundreds,  millions)? 


*  Hundreds  8 

*  Millions  5 

*  Tens  2 

*  Good  and  bad  1 

Does  the  expert  use  a  subset  of  all  possible  solutions? 

*  Small  subset  15 

*  Iterative  1 

How  much  input  data  is  needed  (tens,  hundreds,  thousands)? 

*  Hundreds  9 

*  Thousands  3 

*  Tens  2 


What  kind  of  reasoning  is  required  (certainty,  uncertainty, 
search)? 


Uncertainty  15 

Some  certainty  A 
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What  kinds  of  reasoning  strategies  are  used? 


* 

Gather  program  characteristics  first 

13 

* 

Generate  schedules  by  analogy 

2 

* 

Use  experience 

4 

* 

Layout  roadmap 

1 

* 

Iterative  process 

1 

* 

Coordinate 

1 

Characterization  of  a  Successful  Knowledge -based  System  (KS) 

What  features  are  needed  to  make  a  KS  successful  (graphics,  voice 
I/O,  touch-screen  panel,  integration  with  current  software,  video¬ 
disc  display,  very  fast  response,  zero  incorrect  solutions)? 


*  User-friendly  7 

*  Not  too  slow  7 

*  Graphics  6 

*  Easy  to  understand  1 

*  On-line  documentation  1 

*  Integrate  with  briefing  tools  1 

*  Present  meaningful  information  1 

*  Intelligent  interaction  1 

*  Correlate  to  database  1 

*  Highlight  problems  1 

*  Capture  lessons  learned  1 

*  Touch-screen  panel  1 

*  Videodisc  displays  1 

*  Explanations  1 


What  are  the  potential  benefits  of  a  KS  (conserve  expertise, 
improve  productivity,  training,  reduce  cost)? 


*  Improve  productivity  12 

*  Conserve  expertise  14 

*  Training  use  9 

*  Reduce  cost  6 

*  Evaluate  impacts  1 

*  Lessons  learned  1 

Are  the  risks/costs  acceptable? 

*  Acceptable  4 

*  Limited  investment  1 

What  should  the  design  assume/include  to  avoid  pitfalls? 

*  Assume  inexperienced  user  2 

*  Assume  computer  illiteracy  2 

*  Adapt  to  background  of  user  1 

*  Provide  for  maintainability  1 


% 

1 


n 
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*  Provide  glossary /help 

*  Avoid  technical  jargon 

*  Allow  user  to  override 

*  Must  be  relevant 

*  Provide  immediate  feedback 

Would  a  KS  be  accepted  by  organizational  personnel? 

*  With  some  initial  reluctance 


5.  Defining  the  Prototype 

What  should  the  demonstration  prototype  do? 

*  Solve  specific  problem 

*  Solve  generic  problem 

*  Provide  explanation 

*  Determine  durations 

What  kind  of  knowledge  does  the  prototype  need? 

*  Functional 

*  Program  management 

*  Program  (characteristics) 

*  Regulatory 

*  Threshold  values 

*  Priorities 

What  other  software  should  the  prototype  interface  with? 

*  CSNAS 

*  Scheduling  software 

.  *  AMS 

*  CHART 

*  ALP 

*  Enable 

*  Spreadsheet 

*  None 

Who  needs  to  be  convinced  that  a  KS  is  appropriate? 

*  Upper-level  management  (dictate  use) 

*  PMs 

*  Workers 

What  are  the  Important  acceptance  criteria? 

*  Produce  useful  results 

*  Show  productivity  Improvement 

*  Not  time-consuming 

*  Intelligent  interaction 


1 

1 

1 

1 

1 


6 


9 

7 

1 

1 


7 

7 

3 

1 

1 

1 


4 

3 

2 

1 
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1 
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1 


8 

2 

1 
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* 

★ 


Useful  In  dally  work 
Easy  to  learn 


1 

1 


Defining  the  Operational  System 

What  environment  should  the  operational  system  use? 

*  Personal  computer 

*  Mainframe 

Wh«t  .re  long-ten.  .alntenanc.  and  enh.nce.ent  requirement.? 

*  Relatively  moderate  changes 


15 

4 


10 


Resources  Required 

How  many  different  problems 
solve? 

*  Three 

*  Seven 

*  One 

*  Two 

*  Ten 

*  Twenty  to  thirty 


should  the  demonstration  prototype 

5 

3 

1 

1 

1 

1 


How  many  experts  must  be  consulted? 

*  Six  to  twelve 

*  Twenty  to  forty 

*  Three  to  four 

*  Fifty  to  one  hundred 


U 

2 

1 

1 


Appendix  Ll  Iaska 


This  appendix  contains  the  tasks  defined  during  the  knowledge 
engineering  phase  of  the  thesis.  All  tasks  and  relationships  are 
contained  in  Table  B-l.  The  task  number  matches  the  number  of  the  cor¬ 
responding  event  In  the  Phase  I  model  network.  Letter  Identifiers  are 
included  when  an  event  from  the  Phase  I  network  was  divided  into  multi¬ 
ple  tasks.  Table  B-2  contains  23  tasks  which  may  not  apply  to  a  sched¬ 
ule  for  a  specific  program. 


TABLE  Vll.  Tasks  and  Relationships 


TASK 

DESCRIPTION 

PREDECESSORS 

SUCCESSORS 

1 

DRAFT  PHD 

None 

4 

12 

2 

THREAT  INPUT 

5 

18 

3a 

DRAFT  ILSP 

13a 

3b 

36  38 

3b 

COORDINATE  ILSP 

3a 

48 

4 

ASSESS  COST  SCHED  AS  VBS 

1 

5 

8  10 

5 

FINAL  PHD 

4 

2 

13a 

7a 

DRAFT  CRISP 

13a 

7b 

28  36 

38 

7b 

COORDINATE  CRISP 

7a 

48 

8 

NEW  START  REVIEW 

4 

9 

10 

9 

SECURITY  CLASS  GUIDE 

8  13a 

11 

10 

IPR  PREP 

4  8 

14 

11 

DD254  PREP  &  APPROVAL 

9  14 

40 

12 

AFLC  PAD 

1 

40 

13a 

AFSC  FORM  56  RECEIPT 

5 

3a 

7  a  9 

13b 

13b 

AFSC  FORM  56  RESPONSE 

13a 

14 

24 

14 

IPR 

10  13b 

11 

17  18 

19 

20a  21 

22 

23  27a 

15 

DRAFT  SOW 

20a  23 

28 

29  37 

16 

COST  ESTIMATE 

20a 

27b 

34  36 

17 

DEVELOP  PMP 

14 

40 

18 

DRAFT  SPEC 

2  14 

37 

38 

TABLE  VII.  Tasks  and  Relationships  (Continued) 


TASK 

DESCRIPTION 

PREDECESSORS 

SUCCESSORS 

19 

DEVELOP  TEMP 

14 

40 

20a 

UBS  PREP 

14 

15 

16 

20b 

20b 

UBS  APPROVAL 

20a 

36 

21 

MOA/MOU 

14 

40 

22 

SAFETY  REQUIREMENTS 

14 

40 

23 

PROGRAM  SCHEDULES 

14 

15 

27b 

33 

24 

DRAFT  AP 

13b 

29 

27b 

27a 

ASP  PREP 

14 

27b 

27b 

ASP 

16 

23 

24 

30a 

31 

33 

27a 

34 

35 

37 

43a 

28 

DATA  PACKAGE  PREP 

7a 

15 

37 

40 

29 

SOURCES  SOUGHT  SYNOP 

15 

24 

36 

37 

30a 

SS  PLAN  PREP 

27b 

30b 

43c 

30b 

SS  PLAN  APPROVAL 

30a 

43b 

45 

31 

J&A  PREP 

27b 

39 

33 

PROGRAM  BASELINE 

23 

27b 

40 

34 

COST  BASELINE 

16 

27b 

40 

35 

AP  APPROVAL 

27b 

36 

39 

36 

FINAL  SOW 

3a 

7a 

15 

40 

20b 

29 

35 

37 

37 

DRAFT  RFP 

15 

18 

27b 

36 

38 

28 

29 

38 

FINAL  SPEC 

3a 

7a 

18 

40 

37 

39 

J&A  APPROVAL 

31 

35 

40 

40 

ASD  FORM  117 

11 

12 

17 

41 

19 

21 

22 

28 

33 

34 

36 

38 

39 

41 

RFP  PACKAGE  PREP 

40 

44a 

43a 

SS  STANDARDS  PREP 

27b 

43b 

43b 

SS  STANDARDS  APPROVAL 

30b 

43a 

47 

43c 

SS  PROCEDURES 

30a 

47 

44a 

3-LTR  &  ASD  REVIEWS 

41 

44b 

45 

44b 

AFSC  REVIEW 

44a 

47 

45 

RFP  RELEASE 

30b 

44  a 

46 

46 

CONTRACTOR  RESPONSE 

45 

47 

47 

SOURCE  SELECTION 

43b 

43c 

44b 

48 

46 

48 

CONTRACT  AWARD 

3b 

7b 

47 

None 
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TABLE  VIII  Tasks  Which  Bay  not  Apply 


T  A«K  DESCRIPTION 


2  THREAT  INPUT 

7a  DRAFT  CRISP 

7b  COORDINATE  CRISP 

8  NEW  START  REVIEW 

9  SECURITY  CLASS  CUIDE 

11  DD2 34  PREP  A  APPROVAL 

20b  UBS  APPROVAL 

21  HOA/MOU 

24  DRAFT  AP 

27a  ASP  PREP 

27b  ASP 

28  data  package  prep 

29  SOURCES  SOUGHT  SYNOP 

30a  SS  PLAN  PREP 

30b  SS  PLAN  APPROVAL 

31  J&A  PREP 

33  AP  APPROVAL 

37  DRAFT  RFP 

39  J&A  APPROVAL 

43a  SS  STANDARDS  PREP 

43b  SS  STANDARDS  APPROVAL 

43c  SS  PROCEDURES 

44b  AFSC  REVIEW 


Th«  reaslnder  of  thl a  append  1  *  contain*  brief  de*<  i  1  pt  1  on*  f  1  i .  . 
of  prlaary  responsibility  (OPR),  applicability  and  duration  estimation* 
for  each  cask 


DRAFT  B1C:  This  Cask  represents  the  receipt  of  a  draft  Progtaa  Ha nage 
•ent  Directive  (PHD)  The  OPR  is  the  Prograa  Manager  (  PH  >  and  Pr.^rai 
Eleaent  Monitor  (PEM)  This  task  Is  alvay*  required  Its  dura* lor.  is 
fixed  at  0  days. 

THREAT  INPUT  This  task  represents  the  t  la*  required  to  obtain  r  t ,  r «- « t 
information  concerning  the  prograa  The  OPR  Is  the  PH  and  the  loretg. 
Technology  Division  (PTD)  This  task  Is  not  required  unless  a  threat  ». 
the  systea  exists  Its  duretlon  is  fixed  at  1  aonth 

DRAFT  ILSP :  This  task  rspressnts  the  t  lae  required  to  draft  t  tie  lots 
grated  Logistics  Support  Plan  (ILSP)  The  OPR  Is  the  Dep-  1 1  Y  P  I  I;(|  t  as 


Manager  for  Logiatici  (DPML) .  This  task  Is  always  required  but  should 
no  t  ba  on  Che  critical  path  1 1 »  duration  1*  fixed  at  3  months 


& 


u 


&&M1MLE  1LS f  This  task  represents  the  tlae  required  to  coordinate 
the  ILSP  The  OPR  Is  the  DPML  This  task  Is  always  required  but  should 
not  ba  on  the  critical  path  Its  duration  Is  fixed  at  9  months 

ASSESS  COST  SCHED  AS  WBS  This  task  represents  the  time  required  to 
assess  cost,  schedule,  acquisition  strategy,  and  work  breakdown  struc¬ 
ture  The  OPR  Is  the  PM  and  the  cost  estimator  (RWPE)  This  task  Is 
always  required  Its  duration  Is  estimated  as  follows 

1  Assume  six  week  baseline  for  medium  R&D,  big  Production,  100% 
In  line  Installation 

i  Subtract  one  week  for  small  R AD  (RDT&E  <  $S0M) 

3  Add  three  weeks  for  big  R&D  (RDTAE  >  $?bOM) 

<•  Subtract  one  week  for  small  Production  (production  unit  cost  < 
$?S0F ) 

*>  Add  two  weeks  for  Joint  service  program 

f>  Add  one  week  for  group  cost  A  (plan,  design,  modify) 

1  Add  t  percent  if  100%  retrofit  Installations 

B  Add  IS  percent  If  both  in  line  and  retrofit  installations 
9  Maximum  duration  of  eleven  weeks 

i  I  ML  UUi  Tills  task  represents  the  time  required  to  prepare,  rooidin 
ate  arid  sign  the  Final  PHD  The  OPR  Is  the  PM  and  the  PFJi  Tills  task 
Is  always  required  Its  duration  is  fixed  at  1  month 

L'KAil  lAISf  Tli  I  a  task  represents  the  time  requited  to  draft  the  Compu 
'er  Resources  integrated  Support  Plan  (ORJSPi  TTie  OPR  is  the  PM  at»l 
t he  eng I neer  tRWR)  This  task  Is  not  requited  unless  Mission  '  l  1  '  I  <  a  1 
computer  Re  sour  <  e  s  I  Mi  '  R i  are  used  and  Pr  ogr  am  Management  Responsibility 
Transfer  >  PMR  T  i  Is  planned  !  '  s  duration  depends  on  the  t  y  pe  of  <  ortpu  t 

er  p  r  oi  e  *  s  1  rig  used  and  'ype  d  *<  qu  I  s  1  t  t  on  !>s  du  r  a  *  1  on  Is  e  a  t  |  in  .  r  e  d 

as  foil nws 
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2.  Add  3  veeks  for  ATC  training  requirements. 

3.  Add  4  veeks  for  multiple  using  commands. 

4.  Add  4  veeks  for  SI  requirements. 

5.  Add  2  veeks  for  contractor  maintenance  and  logistics  support. 

NEW  START  REVIEW:  This  task  represents  the  time  required  to  prepare  and 
brief  the  Corporate  Reviev  Group  (CRG)  on  nev  vork  efforts.  The  OPR  is 
the  PH.  This  task  is  not  required  for  follov-on  vork.  Its  duration  is 
fixed  at  3  veeks. 

SECURITY  CLASS  GUIDE:  This  task  represents  the  time  required  to  prepare 
and  approve  a  Security  Classification  Guide  (SCG).  The  OPR  Is  the  PM 
and  RWE.  This  task  is  not  required  for  unclassified  programs.  Its 

duration  depends  on  the  level  of  classification,  type  of  access,  and  the 
presence/absence  of  an  existing  SCG.  Its  duration  is  estimated  as  fol- 
lovs : 

1.  4  months  for  nev  SCG  for  secret  program  vlth  normal  access. 

2.  1  month  to  update  existing  SCG  for  secret  program  vlth  normal 

access . 

3.  5  months  for  nev  SCG  for  secret  program  vlth  special  access 

4.  2  months  to  update  existing  SCG  for  secret  program  vlth 
special  access. 

5.  2  months  for  nev  SCG  for  confidential  program  vlth  normal 

access . 

6.  2  veeks  to  update  existing  SCG  for  confidential  program  vlth 
normal  access. 

7.  3  months  for  nev  SCG  for  confidential  program  vlth  special 

access . 

8.  6  veeks  to  update  existing  SCC  for  confidential  program  vlth 

special  access. 

1PR  PREP:  This  task  represents  the  time  required  to  prepare  for  the 

Internal  Program  Reviev  (IPR).  The  OPR  is  the  PM.  This  task  Is  alvays 
required.  Its  duration  is  fixed  at  2  months. 

DD254  PREP  &  APPROVAL :  This  task  represents  the  time  required  to  pre¬ 
pare  and  approve  DD  Form  254  which  authorizes  contractors  access  to 
classified  data  The  OPR  Is  the  PM  and  RWE.  This  task  Is  not  required 
for  unclassified  programs.  Its  duration  Is  fixed  at  1  month  and  2 

weeks 

AT  LG  PAD :  This  task  represents  the  time  spent  waiting  for  the  Air  Force 
Logistic  Command  Program  Acquisition  Directive  (AFLC  PAD).  The  OPR  Is 
the  DPML  This  task  is  alvays  required.  Its  duration  Is  fixed  at  3 

weeks 

AF3C  FORM  RECEIPT :  This  task  represents  the  time  spent  waiting  for 
the  AFSC  Form  54  The  OPR  is  the  PM.  This  task  Is  alvays  required. 
Its  duration  la  fixed  at  1  month. 


AFSC  FORM  36  RESPONSE :  Th  1 s  Calk  represents  the  tlae  required  to  tevlew 
end  respond  to  the  AFSC  For*  56  The  OPR  Is  the  PM  Thle  task  is  al 
ways  required  Its  duration  is  fixed  at  1  week 

I  PR  This  task  represents  the  t  la*  required  for  the  IPR  This  task  Is 

always  required  The  OPR  la  the  PM  Its  duration  Is  fixed  at  1  day 

DRAFT  SOW  This  task  represents  the  tlae  required  to  draft  the  State 

sent  of  Work  (SOU)  The  OPR  Is  the  PH  and  RUE  This  task  is  always 

required  Its  duration  depends  on  joint  service  involvement  Its  dura 
tlon  is  estiaated  as  follows 

1  30  days  for  single  service  prograa 

2  90  days  for  Joint  service  prograa 

COST  EST 1MATE :  This  task  represents  the  tlae  required  to  develop  a  cost 
estlaate  Th*  OPR  Is  th*  PM  and  RUPE  This  task  is  always  required 

Its  duration  depends  on  the  type/aaK>unt  of  dolls  „  spent,  production 

unit  cost,  joint  systea  lnvolveaent  ,  cost  group,  and  type  of  Installs 
tlon  Its  duration  Is  estiaated  as  follows 

1  As  suae  six  week  baseline  for  aedlua  RAD,  big  Production.  100% 
In-line  Installation 

7  Subtract  one  week  for  saall  RAD  (RDTAE  <  $50M) 

3  Add  three  weeks  for  big  RAD  (RDTAE  >  $750M) 

U  Subtract  one  week  for  saall  Production  (production  unit  cost  < 
$250K) 

5  Add  two  weeks  for  Joint  service  prograa 

6  Add  on*  week  for  group  cost  A  (plan,  design,  aodlfy) 

7  Add  7  percent  If  100%  retrofit  Installations 

8  Add  15  percent  If  both  In-line  and  retrofit  1  ns t a  1 1  a t 1 ons 

9  Maxlaua  duration  of  eleven  weeks. 

DEVELOP  PMP :  This  task  represents  the  tlae  required  to  develop  the 

Prograa  Manageaent  Plan  (PMP).  The  OPR  Is  the  PM  This  task  Is  always 
required.  Its  duration  Is  fixed  at  2  aonths. 

DRAFT  SPEQ :  This  task  represents  the  tlae  required  to  draft  the  techni¬ 
cal  specification.  The  OPR  Is  the  PM  and  RUE  This  task  Is  always 
required.  Its  duration  depends  on  systea  coaplexity  and  Joint  service 
lnvolveaent.  Its  duration  la  estiaated  as  follows: 

1.  Assusm  140  day  baselina  for  alnor  systea  coaplexity  and  single 
service  prograa. 

2.  Add  20  days  for  aajor  systea  coaplexity. 

3.  Add  30  days  for  Joint  service  prograa. 

DEVELOP  TEMP :  This  task  represents  the  tlae  required  to  develop  the 
Test  and  Evaluation  Master  Plan  (TEMP).  The  OPR  Is  the  PM  and  the  test¬ 
er  (RUNT).  This  tssk  Is  always  required.  Its  duration  Is  fixed  at  120 


WBS  PREP :  This  task  represents  the  time  required  to  prepare  the  Work 
Breakdown  Structure  (WBS).  The  OPR  is  the  PM  and  RUPE  This  task  is 
always  required.  Its  duration  Is  fixed  at  1  week 

WBS  APPROVAL :  This  task  represents  the  time  required  to  approve  the 

WBS  The  OPR  Is  the  PM  and  RWPE  This  task  is  not  required  if  the 

acquisition  cost  Is  less  than  $2M.  Its  duration  depends  on  the  amount/ 
type  of  dollars  spent  and  exlstence/absenre  of  a  waiver  (If  applicable) 
Its  duration  Is  estimated  as  follow:: 

1.  Assume  1  week  baseline  for  CAT  2  (RDTAE  <-  $?00M  and  Produc¬ 
tion  <-  $1B) 

2.  Add  20  weeks  for  CAT  1  (RDTAF.  >  $200M  or  Production  >  $  1 B ) 
unless  waived  by  OSD/CAIG. 

MOA/MOU :  This  task  represents  the  time  required  to  prepare,  coordinate, 

and  sign  Memorandur  of  Agreement/Memor anduras  of  Understanding  (MOA/ 

MOU)  .  The  OPR  Is  t.  «  PM  and  program  control  (RWPP).  Tills  task  Is  not 

required  unless  othei  government  agencies  are  involved  in  the  progi am 
Its  duration  Is  fixed  at  130  days. 

SAFETY  REQUIREMENTS :  This  task  represents  the  time  required  to  form 

safety  groups,  review  contractor  analyses,  and  write  SOW/SPEC  para 
graphs  The  OPR  Is  the  safety  officer  (RWS)  This  task  Is  always  re 

qulred.  Its  duration  depends  on  operational  safety  requirements  and 
Joint  service  Involvement.  Its  duration  Is  estimated  as  follows 

1.  Assume  2  week  baseline  for  no  operational  safety  requirements 
and  single  service  program. 

2.  Add  two  weeks  for  operational  safety  requirements 

3.  Add  two  weeks  for  Joint  service  program. 

PROGRAM  SCHEDULES :  This  task  represents  the  time  required  to  prepare 

program  schedules.  The  OPR  is  the  PM.  This  task  Is  always  required 

Its  duration  Is  fixed  at  30  days. 

BBAfI  &E:  This  task  represents  the  time  required  to  draft  the  acquisi¬ 
tion  plan  (AP)  .  The  OPR  Is  the  PM  and  the  contracting  officer  (RWK) 
This  task  Is  not  required  for  work  that  is  within  the  scope  of  an  exist¬ 
ing  contract.  Its  duration  depends  on  the  amount  of  dollars  spent.  Its 
duration  is  estimated  as  follows: 

1.  5  days  for  Informal  plan  (cost  <-  $100K) . 

2.  20  days  for  formal  plan  (cost  >  $100K) . 

ASP  PREP:  This  task  represents  the  time  required  to  prepare  for  the 
acquisition  strategy  panel  (ASP).  The  OPR  is  the  PM  and  RWK.  This  task 
Is  required  whenever  an  AP  Is  prepared.  Its  duration  is  fixed  at  1 
month . 

ASP:  This  task  represents  the  time  required  for  the  ASP.  The  OPR  Is 

the  PM  and  RWK.  This  task  is  required  whenever  an  AP  is  prepared.  Its 


duration  depends  on  the  ( vpe/amount  of  dollars  spent  Its  duration  is 
estimated  as  follows 

1  Assume  1  day  baseline  for  ASD  approval 

2  Add  1  day  for  AKSC  approval  (RDT&E  >—  $200H  or  Production  >— 

SIB) 

LATA  f  ACTA/E  i’Kti'  nils  task  represents  the  time  required  to  prepare 
the  data  package  The  npR  Is  acquisition  support  (RUB)  This  task  is 
not  required  f "i  certain  study  efforts  and  NDI  items  which  are  not  modi¬ 
fied  its  dotation  depends  on  the  type  of  work,  system  complexity, 
joint  service  Involvement  ,  and  type  of  acquisition  Its  duration  is 
estimated  as  follows 


/I  days  for 
progr am 

new  work , 

major 

rompl ex  1 1  y  . 

and 

single 

service 

f>?  days  f  o  i 

p  r  o  g  r  t\  ta 

new  win  k  , 

minor 

comp  1  ex  1 1  y  , 

and 

single 

service 

.1  6?  davs  for  follow  on  work  and  single  service  program 

9  28  days  for  single  service.  QRC  program  with  major  complexity 

U  21  days  for  single  service,  QRC  program  with  minor  complexity 

S  Add  21  days  for  joint  service  program  with  major  complexity 

f>  Add  K  davs  for  joint  service  program  with  minor  complexity. 

K->C'KCLi  iOiMil  SYNQi’  This  task  represents  the  time  required  to  pre¬ 
pare,  publish,  and  receive  replies  to  the  sources  sought  synopsis  The 
DPR  is  the  PH  and  RWK  Th i s  task  is  required  whenever  the  cost  exceeds 
S2MC  unless  the  PM  >  an  justify  proceeding  without  It  Its  duration 
depends  on  t  fie  •  ype  of  -out  tact  pursued  Its  duration  is  estimated  as 
f  n 1  lows 

1  2/  days  for  sole  source  acquisitions 

2  U7  days  for  competitive  acquisitions 

1’LAfi  FREE  T),l  s  task  represents  the  time  required  to  prepare  the 
suture  selection  plan  The  OPR  is  the  PM  This  task  is  not  required 
for  sole  source  a<  qu i s l t 1 ons  or  follow  on  work  Its  duration  depends  on 
tfie  type/amount  of  do  1  1  us  spent  Its  duration  is  estimated  as  follows: 

1  9  weeks  for  ultimate  approval  at  SAF/AQ  (RDT&E  >  $100N  or 
P  ..eduction  •  5'>00M) 

2  6  weeks  for  ultimate  approval  at  ASD/CC  ($f>OM  -  $100N  RDT&E  or 
$100M  -  $500M  Production). 

3  3  weeks  for  approval  at  two-letter  (RDT&E  <  $50M  and  Produc¬ 
tion  <  $100M  or  delegated  by  ASD/CC). 

SS  PLAN  APPROVAL  This  task  represents  the  rime  required  to  coordinate 
and  approve  the  source  selection  plan.  The  OPR  is  the  PM.  This  task  Is 
not  required  for  sole  source  acquisitions  or  follow  on  work.  Its  dura¬ 
tion  depends  on  the  type/amount  of  dollars  spent  Its  duration  Is  esti¬ 
mated  as  follows: 


1. 


6  week*  for  ultimate  approval  at  SAF/AQ  (RDT&E  >  $100M  or 
Production  >  $500M) . 

2.  13  days  for  ultimate  approval  at  ASD/CC  ($bOM  -  $100M  RDT&F.  or 
$100N  *  $500M  Production) 

3.  3  weeks  for  approval  at  two- letter  when  delegated  by  ASD/CC 
A.  1  week  for  approval  at  two-letter  (RDT6.E  <  $SOM  and  Production 

<  $100M). 

J&A  PREP :  This  task  represents  the  time  required  to  prepare  Just  if  lea 
tlon  &  Approval  documentation.  The  OPR  Is  RWX  This  task  Is  required 
only  for  other  than  full  and  open  competition  Its  duration  is  fixed  at 

1  week. 

PROGRAM  BASELINE :  This  task  represents  the  time  required  to  develop  the 
program  baseline.  The  OPR  is  the  PM  This  task  Is  always  required 
Its  duration  depends  on  Joint  service  involvement  Its  duration  is 

estimated  as  follows: 

1.  3  months  for  single  service  program 

2.  6  months  Joint  service  program 

COST  BASELINE :  This  task  represents  the  time  requited  to  develop  the 
cost  baseline.  The  OPR  is  the  PM  and  RW'PF.  Tills  task  Is  alwavs  te 
qulred.  Its  duration  depends  on  the  designation  of  the  piogr.no,  joint 
service  involvement,  and  presence/absence  of  an  existing  cost  baseline 
Its  duration  is  estimated  as  follows 

1.  Assume  3  week  baseline  for  "OTHER  THAN  DESIGNATED"  program, 
single  service  program,  and  no  existing  cost  baseline 

2.  Add  1  week  for  revision  of  existing  cost  baseline 

3.  Add  1  week  for  "SAR"  designation 

A.  Add  2  days  for  "DESIGNATED"  designation 

5.  Add  1  week  for  Joint  service  program 

AZ  APPROVAL:  This  task  repr  esents  the  time  required  to  coordinate  and 
approve  the  AP.  The  OPR  Is  the  PM  and  RWK.  This  task  „s  not  required 
for  work  that  Is  within  the  scope  of  an  existing  contract  Its  duration 
depends  on  the  amount  of  R&D  dollars  spent  Its  duration  is  estimated 
as  follows: 

1.  A  days  for  approval  at  ASD  or  below  (RDT&E  <  $5M)  . 

2.  12A  days  for  approval  at  SAF  (RDT&E  >  $5M) 

FINAL  SOW :  This  task  represents  the  time  required  to  finalize  the  SOW. 
The  OPR  is  the  PM  and  RWE.  This  task  Is  always  required.  Its  duration 
Is  fixed  at  AO  days. 

DRAFT  &££:  This  task  represents  the  time  required  to  prepare  and  re¬ 
ceive  e  response  to  the  dreft  request  for  proposal  (RFP) .  The  OPR  Is 
the  PM  and  RWK.  This  task  Is  required  for  competitive  procurements 
exceeding  $25M  unless  the  PM  can  justify  otherwise  (routine  program, 
standard  contract).  Its  duration  is  fixed  at  17  days. 


FINAL  SPEC :  This  task  represents  the  time  required  to  finalize  the 

technical  specification.  The  OPR  is  the  PM  and  RWE.  This  task  is  al¬ 
ways  required.  Its  duration  depends  on  the  system  complexity  and  Joint 
service  Involvement.  Its  duration  is  estimated  as  follows: 

1.  Assume  110  day  baseline  for  minor  system  complexity  and  single 
service  program. 

2.  Add  15  days  for  major  system  complexity. 

3.  Add  25  days  for  Joint  service  program. 

AAA  APPROVAL :  This  task  represents  the  time  required  to  approve  the 

Justification  &  Approval  documentation.  The  OPR  is  RWK.  This  task  is 
required  only  for  other  than  full  and  open  competition.  Its  duration 
depends  on  the  amount  of  dollars  spent  and  the  amount  of  controversy 
Involved.  Its  duration  is  estimated  as  follows: 

1.  30  days  for  cost  less  than  $30M. 

2.  60  days  for  routine  approval  at  SAF/AQ  (cost  >  $30M) . 

3.  90  days  for  controversial  programs  approved  at  SAF/AQ  (cost  > 

$30M). 

ASP  FORM  117 :  This  task  represents  the  time  required  to  coordinate  and 
approve  ASD  Form  117  (purchase  request  checklist).  This  task  is  always 
required.  The  OPR  is  the  PM.  Its  duration  is  fixed  at  3  weeks. 

RFP  PACKAGE  PREP:  This  task  represents  the  time  required  to  prepare  the 
RFP  package.  The  OPR  is  RtfK.  This  task  is  always  required.  Its  dura¬ 
tion  is  fixed  at  14  days. 

SS  STANDARDS  PREP :  This  task  represents  the  time  required  to  prepare 
the  source  selection  standards.  This  task  is  not  required  for  sole 
source  acquisitions  or  follow-on  work.  Its  duration  depends  on  the 
type/amount  of  dollars  spent.  Its  duration  is  estimated  as  follows: 

1.  9  weeks  for  ultimate  approval  at  SAF/AQ  (RDT&E  >  $100M  or 

Production  >  $500M) . 

2.  6  weeks  for  ultimate  approval  at  ASD/CC  ($50M  -  $100M  RDT&E  or 
$100M  -  $500M  Production). 

3.  3  weeks  for  approval  at  two- letter  (RDT&E  <  $50M  and  Produc¬ 
tion  <  $100M  or  delegated  by  ASD/CC). 

SS  STANDARDS  APPROVAL:  This  task  represents  the  time  required  to  coord¬ 
inate  and  approve  the  source  selection  standards.  The  OPR  is  the  PM. 

This  task  is  not  required  for  sole  source  acquisitions  or  follow-on 

work.  Its  duration  depends  on  the  type/araount  of  dollars  spent.  Its 
duration  is  estimated  as  follows: 

1.  6  weeks  for  ultimate  approval  at  SAF/AQ  (RDT&E  >  $100M  or 

Production  >  $500M) . 

2.  13  days  for  ultimate  approval  at  ASD/CC  ($50M  -  $100M  RDT&E  or 
$100M  -  $500M  Production). 


3. 

4. 


3  weeks  for  approval  at  two- letter  when  delegated  by  ASD/CC. 
1  week  for  approval  at  two-letter  (RDT&E  <  $50M  and  Production 
<  $100M) . 


££  PROCEDURES :  This  task  represents  the  time  required  to  prepare  source 
selection  procedures  and  train  the  source  selection  team.  The  OPR  Is 
the  PM.  This  task  Is  not  required  for  sole  source  acquisitions  or  fol¬ 
low-on  work.  Its  duration  depends  on  the  type/amount  of  dollars  spent. 
Its  duration  Is  estimated  as  follows: 

1.  Assume  10  day  baseline  to  prepare  the  procedures. 

2.  Add  4  weeks  to  schedule  and  conduct  training  for  source 

selections  approved  by  ASD  and  higher  (RDT&E  >  $50M  or 

Production  >  $100M  unless  approval  delegated  to  RW) . 

3-LTR  &  ASD  REVIEWS :  This  task  represents  the  time  required  to  prepare 
for  and  execute  reviews  of  the  RFP  package  at  ASD  and  below.  The  OPR  Is 
the  PM.  This  task  Is  always  required.  Its  duration  depends  on  the 
value  of  the  RFP  package.  Its  duration  Is  estimated  as  follows: 

1.  Assume  15  day  baseline  for  preparation  and  3-LTR  review. 

2.  Add  5  days  for  ASD  review  (RFP  >  $25M) . 

AFSC  REVIEW:  This  task  represents  the  time  required  to  execute  review 
of  the  RFP  package  at  AFSC.  The  OPR  Is  the  PM.  This  task  Is  not  re¬ 
quired  unless  the  RFP  exceeds  $75M.  Its  duration  Is  fixed  at  5  weeks. 

RFP  RELEASE:  This  task  represents  the  time  required  to  finalize  and 
release  the  RFP.  The  OPR  is  RWK.  This  task  Is  always  required.  Its 
duration  Is  dependent  on  the  type  of  contract  and  RFP  value.  Its  dura¬ 
tion  is  estimated  as  follows: 

1.  Assume  5  day  baseline  for  final  modifications. 

2.  Add  55  days  for  single  step  sealed  bid  contract. 

3.  Add  40  days  for  two  step  sealed  bid  contract. 

4.  Add  40  days  for  priced  orders  under  BOA. 

5.  Add  40  days  for  sole  source  contract  exceeding  $25M. 

6.  Add  30  days  for  sole  source  contract  under  $25M. 

7.  Add  40  days  for  competitive  contract  exceeding  $3.5M. 

8.  Add  30  days  for  competitive  contract  under  $3.5M. 

9.  Add  25  days  for  long  lead  contract,  letter  contract,  or 
unpriced  order  under  BOA. 

CONTRACTOR  RESPONSE:  This  task  represents  the  time  spent  waiting  for 
contractor  responses.  The  OPR  Is  the  contractor.  This  task  Is  always 
required.  Its  duration  is  dependent  on  the  type  of  contract  and  RFP 
value.  Its  duration  is  estimated  as  follows: 

1.  45  days  for  single  step  sealed  bid  contract. 

2.  60  days  for  two  step  sealed  bid  contract. 

3.  60  days  for  priced  orders  under  BOA. 

4.  60  days  for  sole  source  contract  exceeding  $25M. 


5.  50  days  for  sole  source  contract  under  $25M. 

6.  60  days  for  competitive  contract  exceeding  $3.5M. 

7.  50  days  for  coapetltlve  contract  under  $3.5K. 

8.  50  days  for  long  lead  contract  or  letter  contract. 

9.  30  days  for  unpriced  order  under  BOA. 

SOURCE  SELECTION :  This  task  represents  the  time  required  to  select  the 
source  The  OPR  Is  the  PM.  This  task  Is  always  required.  Its  duration 
is  dependent  n  the  type  of  contract  and  RFP  value.  Its  duration  Is 
estimated  as  follows: 

1.  95  days  for  priced  orders  under  BOA. 

2.  80  days  for  sole  source  contract  exceeding  $25M. 

3.  68  days  for  sole  source  contract  under  $25M. 

4.  67  days  for  competitive  contract  exceeding  $25M. 

5.  65  days  for  competitive  contract  in  the  $3  5M  -  $25M  range. 

6.  37  days  for  competitive  contract  under  $3  5M. 

7.  68  days  for  long  lead  contract,  letter  contract,  or 
unpriced  order  under  BOA. 

CONTRACT  AWARD:  This  task  represents  the  time  required  to  write,  re¬ 
view,  approve  and  award  the  contract.  The  OPR  is  RWK.  This  task  is 
always  required.  Its  duration  Is  dependent  on  the  type  of  contract  and 
RFP  value.  Its  duration  is  estimated  as  follows: 

1.  54  days  for  single  step  sealed  bid  contract. 

2.  64  days  for  two  step  sealed  bid  contract. 

3.  35  days  for  priced  orders  under  BOA. 

4.  35  days  for  sole  source  contract  exceeding  $25M. 

5.  27  days  for  sole  source  contract  um'er  $25M. 

6.  43  days  for  competitive  contract  exceeding  $3.5M. 

7.  32  days  for  competitive  contract  umer  $3.5M. 

8.  27  days  for  long  lead  contract,  letter  contract,  or  unpriced 

order  under  BOA. 


84 


Program  ChAt.6SLLti_Lsiiti 


This  appendix  contains  listings  of  the  program  chat ac t er 1 s :  1  c s 
identified  during  the  knowl  ige  engineering  phases  of  the  thesis  Table 
C-l  contains  all  the  program  char ac t e r i s t  lc s  and  their  acceptable  val¬ 
ues.  Table  C-2  cross-references  the  program  char ac t er i s t  ic s  with  the 
tasks  (number  from  Table  B-l)  which  use  the  program  char ac t e r  i  s t  i  c  val¬ 
ues  . 


Table  IX  Program  Characterist ics  and  Acceptable  Values 


CHARACTERISTIC 

ACCEPTABLE  VALUES 

PROGRAM  NAME 

String 

SYSTEM  THREAT 

Yes,  No 

RDTE  DOLLARS  ($M) 

2,  5.  10.  25,  50.  100,  200,  250 

PRODUCTION  DOLLARS  ($M) 

2,  5,  10,  50,  100,  500,  1000 

PRODUCTION  UNIT  COST  <$K) 

250 

COST  GROUP 

A,  B 

TYPE  OF  INSTALLATION 

Inline,  Retrofit,  Both 

OTHER  SERVICES 

Acquisition,  Other,  Both,  None 

MCCR  INVOLVED 

Yes,  No 

PMRT  PLANNED 

Yes,  No,  NA 

NDI  ACQUISITION 

Yes,  No 

TYPE  OF  PROCESSING 

Serial,  Other,  NA 

MAI NT/LOG  SUPPORT 

Air  Force,  Contractor,  NA 

ATC  TRAINING 

Yes,  No,  NA 

SPECIAL  INTELLIGENCE 

Yes,  No 

PROGRAM  CLASSIFICATION 

Unclassified,  Confidential, 

Secret 

EXISTING  SCG 

Yes,  No,  NA 

WBS  APPROVAL  WAIVER 

Yes,  No,  NA 

MOA/MOU  NEEDED 

Funding,  Other,  None 

OPERATIONAL  SAFETY 

Yes,  No 

DATA  PACKAGE  NEEDED 

Yes,  No 

RFP  VALUE  ($K) 

25,  3500,  25000,  75000 

SS  DELEGATED  TO  RW 

Yes,  No,  NA 
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Table  IX.  Program  Characteristics  and  Acceptable  Values  (Continued) 


CHARACTERISTIC 

ACCEPTABLE  VALUES 

TYPE  OF  CONTRACT 

One  Step  Sealed  Bid,  Two  Step 
Sealed  Bid,  Priced  Order  Under 

BOA,  Unpriced  Order  Under  BOA, 

Long  Lead,  Letter  Contract, 

Sole  Source,  Competitive 

QRC  PROGRAM 

Yes , 

No 

EXISTING  COST  BASELINE 

Yes , 

No 

PROGRAM  DESIGNATION 

SAR, 

Designated,  Other 

IN  SCOPE  OF  CONTRACT 

Yes , 

No 

CONTROVERSIAL 

Yes , 

No 

FOLLOW-ON  PROGRAM 

Yes , 

No 

SYSTEM  COMPLEXITY 

Yes , 

No 

SOURCES  SOUGHT  SYNOPSIS  NEEDED 

Yes , 

No,  NA 

DRAFT  RFP  NEEDED 

PROGRAM  START  DATE 

CONTRACT  AWARD  DATE 

Yes , 
Date 
Date 

No,  NA 

Table  X.  Cross-reference  of  Characteristics  and  Tasks 


CHARACTERISTIC  TASKS  USED  BY 


PROGRAM  NAME 
SYSTEM  THREAT 
RDTE  DOLLARS  ($M) 

PRODUCTION  DOLLARS  ($M) 

PRODUCTION  UNIT  COST  ($K) 
COST  GROUP 
TYPE  OF  INSTALLATION 
OTHER  SERVICES 

MCCR  INVOLVED 
PMRT  PLANNED 
NDI  ACQUISITION 
TYPE  OF  PROCESSING 
MAINT/LOG  SUPPORT 
ATC  TRAINING 
SPECIAL  INTELLIGENCE 


None 
2  18 


4 

16 

20b 

24 

2  7b 

29 

70s 

30b 

35 

36 

39 

43a 

4  3b 

u  7  . 

20b 

24 

27b 

30a 

30b 

3  S 

39 

43a 

4  3b 

4  3c 

4 

16 

4 

16 

4 

16 

4 

7b 

IS 

It- 

;  8 

'■ 

33 

34 

38 

7a 

-v, 

28 

t . 

i  k 

7a 

7a 

a 

1  v, 

> 

'b 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  »U«CAU  Of  STANe*»W“i*«3- A 


Table  IX.  Program  Characteristics  and  Acceptable  Values  (Continued) 


CHARACTERISTIC 

ACCEPTABLE  VALUES 

TYPE  OF  CONTRACT 

One  Step  Sealed  Bid,  Two  Step 
Sealed  Bid,  Priced  Order  Under 

BOA,  Unpriced  Order  Under  BOA, 

Long  Lead,  Letter  Contract, 

Sole  Source,  Competitive 

QRC  PROGRAM 

Yes, 

No 

EXISTING  COST  BASELINE 

Yes , 

No 

PROGRAM  DESIGNATION 

SAR, 

Designated,  Other 

IN  SCOPE  OF  CONTRACT 

Yes, 

No 

CONTROVERSIAL 

Yes , 

No 

FOLLOW-ON  PROGRAM 

Yes, 

No 

SYSTEM  COMPLEXITY 

Yes , 

No 

SOURCES  SOUGHT  SYNOPSIS  NEEDED 

Yes , 

No,  NA 

DRAFT  RFP  NEEDED 

PROGRAM  START  DATE 

CONTRACT  AWARD  DATE 

Yes , 
Date 
Date 

No,  NA 

Table  X.  Cross-reference  of  Characteristics  and  Tasks 


CHARACTERISTIC 

TASKS  USED  BY 

PROGRAM  NAME 

None 

SYSTEM  THREAT 

2 

18 

RDTE  DOLLARS  ($M) 

4 

16 

20b 

24 

27b 

29 

30a 

30b 

35 

36 

39 

43a 

43b 

43c 

PRODUCTION  DOLLARS  ($M) 

20b 

24 

27b 

30a 

30b 

35 

36 

39 

43a 

43b 

43c 

PRODUCTION  UNIT  COST  ($K) 

4 

16 

COST  GROUP 

4 

16 

TYPE  OF  INSTALLATION 

4 

16 

OTHER  SERVICES 

4 

7b 

15 

16 

18 

22 

28 

33 

34 

38 

MCCR  INVOLVED 

7a 

7b 

28 

36 

38 

48 

PMRT  PLANNED 

7a 

NDI  ACQUISITION 

7a 

TYPE  OF  PROCESSING 

7a 

MAINT/LOG  SUPPORT 

7b 

ATC  TRAINING 

7b 

SPECIAL  INTELLIGENCE 

7b 

9 
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Table  X.  Cross-reference  of  Characteristics  and  Tasks  (Continued) 


CHARACTERISTIC 

TASKS  USED  BY 

PROGRAM  CLASSIFICATION 

9 

11 

12 

40 

EXISTING  SCG 

9 

WBS  APPROVAL  WAIVER 

20b 

MOA/MOU  NEEDED 

21 

40 

OPERATIONAL  SAFETY 

22 

DATA  PACKAGE  NEEDED 

28 

37 

40 

RFP  VALUE  <$K) 

29 

44a 

44b 

45 

46 

47 

48 

SS  DELEGATED  TO  RW 

30b 

43b 

43c 

TYPE  OF  CONTRACT 

29 

30a 

30b 

31 

39 

40 

43a 

43b 

43c 

45 

46 

47 

48 

QRC  PROGRAM 

28 

EXISTING  COST  BASELINE 

34 

PROGRAM  DESIGNATION 

34 

IN  SCOPE  OF  CONTRACT 

24 

27a 

27b 

30a 

30b 

31 

33 

34 

35 

36 

37 

39 

43a 

43b 

43c 

45 

47 

48 

CONTROVERSIAL 

39 

FOLLOW-ON  PROGRAM 

8 

9 

28 

30a 

30b 

31 

39 

40 

43a 

43b 

43c 

45 

47 

48 

SYSTEM  COMPLEXITY 

18 

28 

38 

SOURCES  SOUGHT  SYNOPSIS  NEEDED 

24 

29 

36 

37 

DRAFT  RFP  NEEDED 

36 

37 

38 

40 

PROGRAM  START  DATE 

1 

! 

CONTRACT  AWARD  DATE 

48 

_ 

87 


APPgfldlX  Rules  for 


Schedule  Generation 

This  appendix  contains  the  rules  used  for  schedule  generation.  The 
rules  are  written  In  Guru.  Variable  "ASKDONE"  Is  set  to  "TRUE"  before 
consulting  the  rule  set.  All  other  variable  names  are  In  lower  case 
letters.  Variables  beginning  with  the  letter  "t"  are  initialized  to 
"UNKNOWN"  before  consulting  the  rules.  Variables  beginning  with  the 
letter  "v"  are  initialized  to  the  values  of  the  program  characteristics 
before  consulting  the  rules . 


RULE:  RDPMD 

PRIORITY:  90 

TEST:  E 

IF:  ASKDONE 

THEN:  PERFORM  ADDTASK 

CURRTASK.DUR  -  "  0" 

CURRTASK . DESCR  -  "DRAFT  PMD 
CURRTASK . OPR  -  "PM  &  PEM 
CURRTASK. US  -  vstart 
CURRTASK. UC  -  vstart 
tdpmd  -  CURRTASK. ID 

REASON:  The  start  event  for  the  network  Is  the  Draft  PMD.  Its 
actual  duration  takes  months.  However,  it  is  treated  as 
a  milestone  event  for  schedule  development. 

COMMENT:  Draft  PMD.  Sources:  LTC  Hollingsworth,  x54811;  LTC 
Sikra,  x53969. 

Event  1  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RTHRT 

PRIORITY:  80 
TEST :  E 

IF:  vthreat  -  "YES"  and  KNOWN (tfpmd) 

THEN:  PERFORM  ADDTASK 

CURRTASK.DUR  -  "  23" 

CURRTASK. DESCR  -  "THREAT  INPUT 
CURRTASK. OPR  -  "PM  &  FTD 
t threat  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tfpmd 
CURRLINK. SUCC  -  tthreat 

REASON:  Threat  Input  follows  receipt  of  the  Final  PMD  and  takes 


4  weeks  to  complete.  This  task  is  not  used  if  there  is 
not  a  threat  to  the  system  being  developed. 

COMMENT:  Threat  Input.  Source,  LT  Rohner,  x?????;  LTC 
Hollingsworth,  x54811. 

Event  2  in  RW  Phase  I  network,  30  Aug  85. 


RDILSP 

PRIORITY:  80 

TEST:  E 

IF:  KNOWN (tform56i) 

THEN:  PERFORM  ADDTASK 

CURRTASK . DUR  -  "  65" 

CURRTASK . DESCR  -  "DRAFT  ILSP 
CURRTASK. OPR  -  "DPML  " 

tdilsp  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tform56i 
CURRLINK. SUCC  -  tdilsp 

REASON:  Draft  ILSP  follows  receipt  of  AFSC  Form  56  takes  65  days 
to  complete. 

COMMENT:  Draft  ILSP.  Source,  John  Shawhan,  x52108. 

Event  3  in  RW  Phase  I  network,  30  Aug  85. 


RCILSP 

PRIORITY:  80 

TEST:  E 

IF:  KNOWN (tdilsp) 

THEN:  PERFORM  ADDTASK 

CURRTASK. DUR  -  "  195" 

CURRTASK. DESCR  -  "COORDINATE  ILSP 

CURRTASK. OPR  -  "DPML 

tcilsp  -  CURRTASK. ID 

ATTACH  1  TO  CURRLINK 

CURRLINK. PRED  -  tdilsp 

CURRLINK. SUCC  -  tcilsp 

REASON:  Coordinate  ILSP  follows  Develop  ILSP  and  takes  195  days 
to  complete. 

COMMENT:  Coordinate  ILSP.  Source,  John  Shawhan,  x52108. 

Event  3  in  RW  Phase  I  network,  30  Aug  85. 


RACSAW 

PRIORITY:  90 
TEST :  E 

IF:  KNOWN (tdpmd) 

THEN:  PERFORM  ADDTASK 

duration  -  40 
IF  vrdte  <  50  THEN 

duration  -  duration  *  5 
ELSE 


IF  vrdte  >  250  THEN 

duration  -  duration  +  15 
ENDIF 
END  IF 

IF  vunit  <  250  THEN 

duration  -  duration  *  5 
ENDIF 

IF  vjoint  -  "NONE"  THEN 
duration  -  duration  -  10 
ENDIF 

IF  vgroup  -  "A"  THEN 
duration  -  duration  +  5 
ENDIF 

IF  vinst  -  "RETROFIT"  THEN 
duration  -  duration  *  .07 
ELSE 

IF  vinst  -  "BOTH"  THEN 
duration  -  duration  *  .15 
ENDIF 
ENDIF 

IF  duration  >  55  THEN 
duration  -  55 
ENDIF 

CURRTASK.DUR  -  TOSTR(duration, 5 ,0) 

CURRTASK . DESCR  -  "ASSESS  COST  SCHED  AS  WBS" 

CURRTASK . OPR  -  "PM  &  RWPE 
tacsaw  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tdpmd 
CURRLINK . SUCC  -  tacsaw 

REASON:  Assess  Cost,  Schedule,  Acquisition  Strategy,  and  Work 
Breakdown  Structure  follows  completion  of  Draft  PMD. 

Its  duration  depends  on  RDTE  cost,  Production  Unit  Cost, 
Joint  service  involvement,  Cost  Group,  and  Type  of 
Installation.  It  takes  no  longer  than  11  weeks  to 
complete. 

COMMENT:  Assess  Cost,  Schedule,  Acquisition  Strategy,  and  Work 
Breakdown  Structure.  Source,  John  Holdren,  x52651. 

Event  4  in  RW  Phase  I  network,  30  Aug  85. 


RFPMD 

PRIORITY:  90 
TEST :  E 

IF:  KN0WN( tacsaw) 

THEN:  PERFORM  ADDTASK 

CURRTASK.DUR  -  "  23" 

CURRTASK. DESCR  -  "FINAL  PMD 
CURRTASK. OPR  -  "PM  &  PEM 
tfpad  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tacsaw 


CURRLINK.SUCC  -  tfpmd 

REASON:  The  Final  PMD  follows  Assessment  of  Cost,  Schedule, 
Acquisition  Strategy,  and  Vork  Breakdown  Structure. 
It  takes  4  weeks  to  complete. 

COMMENT:  Final  PMD.  Source:  LTC  Hollingsworth,  x54811. 
Event  5  in  RV  Phase  I  network,  30  Aug  85. 


RULE:  RDCRISP 

PRIORITY:  80 
TEST:  E 

IF:  vmccr  -  "YES"  and  vpmrt  -  "YES"  and  KNOWN(tform56i) 

THEN:  PERFORM  ADDTASK 

duration  -  25 
IF  vproc  -  "SERIAL"  THEN 
duration  -  duration  -  5 
ENDIF 

IF  vndl  O  "NO"  THEN 

duration  -  duration  +  20 
ENDIF 

CURRTASK . DUR  -  T0STR(duration,5,0) 

CURRTASK . DESCR  -  "DRAFT  CRISP 
CURRTASK. OPR  -  "PM  &  RWE 
tdcrisp  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tform561 
CURRLINK.SUCC  -  tdcrisp 

REASON:  Draft  CRISP  follows  receipt  of  AFSC  Form  56.  Its 
duration  depends  on  the  type  of  processing  involved 
complete.  This  task  Is  not  needed  unless  the  system 
uses  Mission  Critical  Computer  Resources. 

COMMENT:  Draft  CRISP.  Sources:  Capt  Schmitt,  x52665;  LTC 
Hollingsworth,  x54811. 

Event  7  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RCCRISP 

PRIORITY:  80 
TEST:  E 

IF:  KN0WN( tdcrisp) 

THEN:  PERFORM  ADDTASK 

duration  -  150 
IF  vatc  -  "YES"  THEN 
duration  -  duration  +  15 
ENDIF 

IF  vjoint  -  "NONE"  THEN 
duration  -  duration  -  20 
ENDIF 

IF  vs 1  -  "YES"  THEN 
duration  -  duration  +  20 
ENDIF 

IF  vmaint  -  "CONTRACTOR"  THEN 
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duration  -  duration  +  10 
ENDIF 

CURRTASK . DUR  -  TOSTR(duration, 5 , 0) 

CURRTASK . DESCR  -  "COORDINATE  CRISP  " 

CURRTASK. OPR  -  "PM  &  RWE  " 
tccrisp  -  CURRTASK.  ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tdcrisp 
CURRLINK. SUCC  -  tccrisp 

REASON:  Coordinate  CRISP  follows  develop  CRISP.  Its  duration 
depends  on  the  ATC  training  requirements,  Joint  service 
involvement,  Special  Intelligence  requirements,  and  the 
source  of  maintenance  and  logistics  support.  This  task 
is  not  needed  unless  the  system  uses  Mission  Critical 
Computer  Resources. 

COMMENT:  Coordinate  CRISP.  Sources:  Capt  Schmitt,  x52665;  LTC 
Hollingsworth,  x54811. 

Event  7  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RNSR 

PRIORITY:  90 
TEST:  E 

IF:  vfollow  -  "NO"  and  KNOWN(tacsaw) 

THEN:  PERFORM  ADDTASK 

CURRTASK. DUR  -  "  15" 

CURRTASK. DESCR  -  "NEW  START  REVIEW 

CURRTASK. OPR  -  "PM 

tnsr  -  CURRTASK. ID 

ATTACH  1  TO  CURRLINK 

CURRLINK. PRED  -  tacsaw 

CURRLINK. SUCC  -  tnsr 

REASON:  The  New  Start  Review  follows  Assessment  of  Cost, 
Schedule,  Acquis tion  Strategy,  and  Work  Breakdown 
Structure.  Its  duration  is  15  days  including 
preparation.  It  is  not  needed  for  follow-on  programs. 
COMMENT:  New  Start  Review.  Sources;  LTC  Hollingsworth,  x54811; 
LTC  Sikra,  x53969. 

Event  8  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RSCG 

PRIORITY:  80 
TEST:  E 

IF:  vclass  O  "UNCLASSIFIED"  and  KNOWN(tform56i)  and 

(KNOWN (tnsr)  or  vfollow  -  "YES") 

THEN:  PERFORM  ADDTASK 

IF  vclass  -  "CONFIDENTIAL"  and  vscg  -  "NO"  THEN 
duration  -  45 
ENDIF 

IF  vclass  -  "CONFIDENTIAL"  and  vscg  -  "YES"  THEN 
duration  -  10 
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END  IF 

IF  vclass  -  "CONFIDENTIAL"  and  vsi  -  "YES"  and  \ 
vscg  -  "NO"  THEN 
duration  -  68 
END  IF 

IF  vclass  -  "CONFIDENTIAL"  and  vsi  -  "YES"  and  \ 
vscg  -  "YES"  THEN 
duration  -  30 
END  IF 

IF  vclass  -  "SECRET"  and  vscg  -  "NO"  THEN 
duration  -  90 
END  IF 

IF  vclass  -  "SECRET"  and  vscg  -  "YES"  THEN 
duration  -  23 
END  IF 

IF  vclass  -  "SECRET"  and  vsi  -  "YES"  and  \ 
vscg  -  "NO"  THEN 
duration  -  113 
ENDIF 

IF  vclass  -  "SECRET"  and  vsi  -  "YES"  and  \ 
vscg  -  "YES"  THEN 
duration  -  45 
ENDIF 

CURRTASK . DUR  -  T0STR(duration,5,0) 

CURRTASK . DESCR  -  "SECURITY  CLASS  GUIDE  " 

CURRTASK. OPR  -  "PH  &  RWE 
tscg  -  CURRTASK. ID 
IF  KNOWN(tnsr)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tnsr 
CURRLINK. SUCC  -  tscg 
ENDIF 

ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tform56i 
CURRLINK. SUCC  -  tscg 

REASON:  Security  Classification  Guide  preparation  follows  the 
New  Start  Review  (if  used)  and  receipt  of  AFSC  Form  56. 
This  task  is  not  used  if  the  program  is  unclassified. 
COMMENT:  Security  Classification  Guide.  Sources:  Dave  Garcher, 
x53218;  LTC  Hollingsworth,  x54811. 

Event  9  in  Rtf  Phase  I  network,  30  Aug  85. 


RULE:  RIPRP 

PRIORITY:  90 
TEST:  E 

IF:  (vfollow  -  "YES"  and  KNOWN(tacsaw) )  or  KNOWN(tnsr) 

THEN:  PERFORM  ADDTASK 

CURRTASK. DUR  -  "  45" 

CURRTASK. DESCR  -  "I PR  PREP 
CURRTASK. OPR  -  "PM  " 

tiprp  -  CURRTASK. ID 


IF  KNOWN ( t ns r)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tnsr 
CUFRLINK . SUCC  -  tiprp 
ELSE 

ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tacsaw 
CURRLINK. SUCC  -  tiprp 
END  IF 

REASON:  IPR  preparation  follows  the  New  Start  Review  (if  used). 
IPR  preparation  follows  Assessment  of  Cost,  Schedule, 
Acquisition  Strategy,  and  Work  Breakdown  Structure  for 
follow-on  programs.  Its  duration  is  45  days. 

COMMENT:  IPR  Preparation.  Sources:  LTC  Hollingsworth,  x54811; 
LTC  Sikra,  x53969. 

Event  10  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RDD254 

PRIORITY:  70 
TEST:  E 

IF:  KNOWN(tscg)  and  KNOWN(tipr) 

THEN:  PERFORM  ADDTASK 

CURRTASK.DUR  -  "  33" 

CURRTASK . DESCR  -  "DD  254  PREP  &  APPROVAL  " 

CURRTASK . OPR  -  "PM  &  RWE 
tdd254  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tscg 
CURRLINK. SUCC  -  tdd254 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tipr 
CURRLINK. SUCC  -  tdd254 

REASON:  DD  Form  254  preparation  and  approval  follows  the 
Security  Classification  Guide  and  Internal  Program 
Review.  Its  duration  is  33  days.  This  task  is  not  used 
in  unclassified  programs. 

COMMENT:  DD  Form  254.  Source:  Dave  Garcher,  x53218;  LTC 
Hollingsworth,  x54811. 

Event  11  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RPAD 

PRIORITY:  90 
TEST:  E 

IF:  KNOWN  (tdpmd) 

THEN:  PERFORM  ADDTASK 

CURRTASK.DUR  -  "  15" 

CURRTASK. DESCR  -  "AFLC  PAD 
CURRTASK. OPR  -  "DPML 
tpad  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 


v 

v*1 

V 

•IV 

g 


$ 


i 


*'w 

:S 


V? 

y  ** 

v. 

§ 

<  Vi 

•v 


$ 


1 


9 

I 

5 

*v. 


RULE: 
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CURRLINK . PRED  -  tdpmd 
CURRLINK . SUCC  -  tpad 

REASON:  The  AFLC  Program  Acquisition  Directive  follows  the 
receipt  of  the  Final  PMD.  Its  duration  is  15  days. 
COMMENT:  AFLC  PAD.  Source:  LTC  Hughes,  x54852. 

Event  12  in  RW  Phase  I  network,  30  Aug  85. 


RFORM56I 
PRIORITY: 
TEST:  E 

IF:  K] 

THEN:  P! 


IF:  KNOWN (tfpmd) 

THEN:  PERFORM  ADDTASK 

CURRTASK . DUR  -  "  23" 

CURRTASK . DES CR  -  "AFSC  FORM  56  RECEIPT  " 

CURRTASK. OPR  -  "PM  * 

tform56i  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tfpmd 
CURRLINK. SUCC  -  tform56i 

REASON:  AFSC  Form  56  is  received  after  the  Final  PMD  is 
completed.  Its  duration  is  23  days. 

COMMENT:  AFSC  Form  56  Receipt.  Sources:  LTC  Hollingsworth, 
x54811;  LTC  Sikra,  x53969. 

Event  13  in  RW  Phase  I  network,  30  Aug  85. 


RF0RM560 

PRIORITY: 


TEST: 

IF: 

THEN: 


KNOWN (tform56i) 
PERFORM  ADDTASK 
CURRTASK. DUR  -  " 


CURRTASK. DES CR  -  "AFSC  FORM  56  RESPONSE 

CURRTASK. OPR  -  "PM 

tform56o  -  CURRTASK. ID 

ATTACH  1  TO  CURRLINK 

CURRLINK. PRED  -  tform56i 

CURRLINK. SUCC  -  tform56o 

REASON:  AFSC  Form  56  must  be  reviewed  and  a  response  made  in  5 
days. 

COMMENT:  AFSC  Form  56  Response.  Sources:  LTC  Hollingsworth, 
x54811;  LTC  Sikra,  x53969. 

Event  13  in  RW  Phase  I  network,  30  Aug  85. 


RIPR 

PRIORITY:  80 
TEST:  E 

IF:  KNOWN (tform56o)  and  KNOWN(tlprp) 

THEN:  PERFORM  ADDTASK 

CURRTASK. DUR  -  "  1" 
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CURRTASK . DESCR  -  "I PR 
CURRTASK . OPR  -  "PM 
tipr  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tfonn56o 
CURRLINK . SUCC  -  tlpr 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tlprp 
CURRLINK. SUCC  -  tipr 

REASON:  The  Internal  Program  Review  follows  the  response  to  the 
AFSC  Form  56  and  IPR  preparation.  Its  duration  is  1 
day . 

COMMENT:  IPR.  Sources:  LTC  Hollingsworth,  x54811;  LTC  Sikra, 
x53969. 

Event  14  in  RW  Phase  I  network,  30  Aug  85. 


RDSOW 
PRIORITY: 
TEST:  E 

IF:  K> 

THEN:  PI 


IF:  KNOWN (twbsp)  and  KNOWN (tsched) 

THEN:  PERFORM  ADDTASK 

CURRTASK. DUR  -  "  90" 

IF  vjoint  -  "NONE"  THEN 
CURRTASK. DUR  -  "  30" 

END  IF 

CURRTASK. DESCR  -  "DRAFT  SOW 
CURRTASK. OPR  -  "PM  &  RWE 
tdsow  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  twbsp 
CURRLINK. SUCC  -  tdsow 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tsched 
CURRLINK. SUCC  -  tdsow 

REASON:  The  Draft  SOW  follows  WBS,  Program  Schedules,  and  Draft 
ILSP.  Its  duration  depends  on  joint  service 
involvement . 

COMMENT:  Draft  SOW.  Source:  LTC  Hollingsworth,  x54811. 

Event  15  in  RW  Phase  I  network,  30  Aug  85. 


RCOSTEST 
PRIORITY:  70 
TEST :  E 

IF:  KNOWN (twbsp) 

THEN:  OBTAIN  FROM  CURRTASK  FOR 

DESCR  -  "ASSESS  COST  SCHED  AS  WBS" 
duration  -  CURRTASK. DUR 
PERFORM  ADDTASK 
CURRTASK. DUR  -  duration 
CURRTASK. DESCR  -  "COST  ESTIMATE 
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CURRTASK . OPR  -  "PH  &  RWPE 
tcostest  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  twbsp 
CURRLINK. SUCC  -  tcostest 

REASON:  The  Post-IPR  Cost  Estimate  follows  the  IPR  and  WBS 

preparation.  Its  duration  is  the  same  as  the  first  cost 
estimate. 

COMMENT:  Post-IPR  Cost  Estimate.  Source:  John  Holdren,  x52651. 
Event  16  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RPMP 

PRIORITY:  80 
TEST:  E 

IF:  KNOWN(tlpr) 

THEN:  PERFORM  ADDTASK 

CURRTASK. DUR  -  "  45" 

CURRTASK. DESCR  -  "DEVELOP  PMP 
CURRTASK. OPR  -  "PM 
tpmp  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tipr 
CURRLINK. SUCC  -  tpmp 

REASON:  The  Program  Management  Plan  follows  the  IPR.  Its 
duration  is  45  days. 

COMMENT:  PMP.  Source:  LTC  Hollingsworth,  x52651. 

Event  17  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RDSPEC 

PRIORITY:  80 
TEST:  E 

IF:  KNOWN(tipr)  and  (KNOWN(tthreat)  or  vthreat  O  "YES") 

THEN:  PERFORM  ADDTASK 

duration  -  140 
IF  vscomp  -  "MAJOR"  THEN 
duration  -  duration  +  20 
ENDIF 

IF  vjoint  -  "NONE"  THEN 
duration  -  duration  -  30 
ENDIF 

CURRTASK. DUR  -  T0STR(duration, 5 ,0) 

CURRTASK. DESCR  -  "DRAFT  SPEC 
CURRTASK. OPR  -  "PM  &  RWE 
tdspec  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tipr 
CURRLINK. SUCC  -  tdspec 
IF  KNOWN(tthreat)  THEN 


ATTACH  1  TO  CURRLINK 


CURRLINK . SUCC  -  tdspec 
END  IF 

REASON:  The  Dra£t  Specification  follows  the  IPR  and  Threat  Input 
(if  used).  Its  duration  depends  on  System  Complexity 
and  Joint  service  involvement. 

COMMENT:  Draft  Specification.  Source:  Phase  I  Scheduling 
Guide . 

Event  18  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RTEMP 

PRIORITY:  80 
TEST:  E 

IF:  KNOWN(tipr) 

THEN:  PERFORM  ADDTASK 

CURRTASK.DUR  -  *  120" 

CURRTASK . DESCR  -  "DEVELOP  TEMP 
CURRTASK . OPR  -  "PM  &  RWNT 
ttemp  -  CURRTASK.  ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tipr 
CURRLINK. SUCC  -  ttemp 

REASON:  Development  of  the  TEMP  follows  the  IPR.  Its  duration 
is  120  days. 

COMMENT:  Develop  TEMP.  Source:  Phase  I  Scheduling  Guide. 
Event  19  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RWBSP 

PRIORITY:  80 
TEST:  E 

IF:  KNOWN (tipr) 

THEN:  PERFORM  ADDTASK 

CURRTASK.DUR  -  "  5" 

CURRTASK. DESCR  -  "WBS  PREP 
CURRTASK. OPR  -  "PM  &  RWPE  " 
twbsp  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tipr 
CURRLINK. SUCC  -  twbsp 

REASON:  WBS  Preparation  follows  the  IPR.  Its  duration  is  5 
days. 

COMMENT:  WBS  Preparation.  Source:  John  Holdren,  x52651. 
Event  20  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RWBSA 

PRIORITY:  80 
TEST:  E 

IF:  KNOWN(twbsp)  and  (vrdte  >  2  or  vprod  >  2) 

THEN:  PERFORM  ADDTASK 

duration  -  10 
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IF  vrdte  >  200  or  vprod  >  1000  THEN 
IF  vwbs  -  "NO"  THEN 
duration  -  100 
END  IF 
END  IF 

CURRTASK . DUR  -  T0STR(duration, 5 , 0) 

CURRTASK.  DESCR  -  "WBS  APPROVAL 
CURRTASK. OPR  -  "PM  &  RWPE  • 
twbsa  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tvbsp 
CURRLINK. SUCC  -  twbsa 

REASON:  WBS  Approval  follows  the  IPR  and  WBS  Preparation.  Its 
duration  depends  on  RDTE  dollars,  Production  dollars, 
and  OSD/CAIG  waiver  (if  needed). 

COMMENT:  WBS  Approval.  Source:  John  Holdren,  x52651. 

Event  20  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RMOA 

PRIORITY:  80 
TEST :  E 

IF:  vmoa  O  "NONE"  and  KNOWN(tipr) 

THEN:  PERFORM  ADDTASK 

CURRTASK. DUR  -  "  130" 

CURRTASK. DESCR  -  "MOA/MOU 
CURRTASK. OPR  -  "PM  &  RWPP 
tmoa  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tipr 
CURRLINK. SUCC  -  tmoa 

REASON:  MOA/MOU  follows  the  IPR.  Its  duration  is  130  days. 
COMMENT:  WBS  Preparation.  Source:  LTC  Hollingsworth,  x54811. 

Event  21  in  RW  Phase  I  network,  30  Aug  85. 


RULE: 


RSAFETY 
PRIORITY: 
TEST:  E 

IF: 

THEN: 


80 


KNOWN(tipr) 

PERFORM  ADDTASK 
duration  -  20 
IF  vsafe  -  "YES"  THEN 

duration  -  duration  +  10 
END  IF 

IF  vjoint  -  "NONE"  THEN 
duration  -  duration  -  10 
END  IF 

CURRTASK. DUR  -  T0STR(duration,5,0) 

CURRTASK. DESCR  -  "SAFETY  REQUIREMENTS’ 

CURRTASK. OPR  -  "RWS 
tsafe  -  CURRTASK. ID 
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ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tipr 
CURRLINK. SUCC  -  Csafe 

REASON:  Safety  Requirements  follow  the  IPR.  Its  duration 
depends  on  Operational  Safety  and  Joint  service 
involvement. 

COMMENT:  Safety  Requirements.  Source:  Mr.  Bigi,  x59249. 
Event  22  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RSCHED 

PRIORITY:  80 
TEST :  E 

IF:  KNOWN (tipr) 

THEN:  PERFORM  ADDTASK 

CURRTASK . DUR  -  "  30" 

CURRTASK . DESCR  -  "PROGRAM  SCHEDULES 

CURRTASK. OPR  -  "PM 

tsched  -  CURRTASK. ID 

ATTACH  1  TO  CURRLINK 

CURRLINK. PRED  -  tipr 

CURRLINK. SUCC  -  tsched 

REASON:  Program  Schedules  follow  the  IPR.  Its  duration  is  30 
days. 

COMMENT:  Program  Schedules . Source :  LTC  Hollingsworth,  x54811. 
Event  23  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RDAP 

PRIORITY:  70 
TEST :  E 

IF:  vinscope  -  "NO"  and 

( (KNOWN(tform56o)  and  vsssn  O  "YES")  or  KNOWN(tsss)) 
THEN:  PERFORM  ADDTASK 

IF  vrdte  >  0  or  (vprod*1000)  >  100  THEN 
duration  -  "  20" 

ELSE 

duration  -  "  5" 

ENDIF 

CURRTASK. DUR  -  duration 
CURRTASK. DESCR  -  "DRAFT  AP 
CURRTASK. OPR  -  "PM  &  RWK 
tdap  -  CURRTASK. ID 
IF  KNOWN(tsss)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tsss 
CURRLINK. SUCC  -  tdap 
ELSE 

ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tform56o 
CURRLINK. SUCC  -  tdap 
ENDIF 


REASON:  Develop  Acquisition  Plan  follows  the  Sources  Sought 
Synopsis  (if  used)  or  receipt  of  AFSC  Form  56.  Its 
duration  depends  on  the  type  and  amount  of  dollars  to  be 
spent.  This  task  is  not  needed  for  follow-on  efforts. 
COMMENT:  Develop  Acquisition  Plan.  Source:  Jim  Shaeffer,  52336. 
Event  24  in  Rtf  Phase  I  network,  30  Aug  85. 


RULE:  RASPP 

PRIORITY:  80 
TEST:  E 

IF:  vinscope  -  "NO*  and  KNOWN(tipr) 

THEN:  PERFORM  ADDTASK 

CURRTASK . DUR  -  ■  30" 

CURRTASK . DESCR  -  "ASP  PREP 
CURRTASK. OPR  -  "PM  6c  RWK  " 
taspp  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tipr 
CURRLINK. SUCC  -  taspp 

REASON:  Acquisition  Strategy  Panel  Preparation  follows  the  IPR. 
Its  duration  is  30  days.  This  task  is  not  needed  for 
follow-on  efforts. 

COMMENT:  Acquisition  Strategy  Panel  Preparation.  Source:  Jim 
Shaeffer,  x52336. 

Events  25  and  27  in  Rtf  Phase  I  network,  30  Aug  85. 


RULE:  RASP 

PRIORITY:  70 
TEST:  E 

IF:  KNOWN(tcostest)  and  KNOWN(tsched)  and  KNOWN(tdap)  and 

KNOWN (taspp) 

THEN:  PERFORM  ADDTASK 

IF  vrdte  <  200  and  vprod  <  1000  THEN 
duration  -  "  1" 

ELSE 

duration  -  "  2" 

END  IF 

CURRTASK. DUR  -  duration 
CURRTASK. DESCR  -  "ASP 
CURRTASK. OPR  -  "PM  &  RWK 
tasp  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tcostest 
CURRLINK. SUCC  -  tasp 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tsched 
CURRLINK. SUCC  -  tasp 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdap 
CURRLINK. SUCC  -  tasp 


ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  Caspp 
CURRLINK. SUCC  -  tasp 

REASON:  The  Acquisition  Strategy  Panel  follows  Acquisition 

Strategy  Panel  Preparation,  the  Post-IPR  Cost  Estimate, 
development  of  Program  Schedules,  and  development  of  the 
Draft  Acquisition  Plan.  Its  duration  depends  on  the 
amount  and  type  of  dollars  spent.  This  task  is  not 
needed  for  follow-on  efforts. 

COMMENT:  Acquisition  Strategy  Panel.  Source:  Jim  Shaeffer, 
X52336. 

Events  25  and  27  in  RV  Phase  I  network,  30  Aug  85. 


RULE:  RDATA 

PRIORITY:  80 
TEST:  E 

IF:  vdata  -  "YES"  and 

(KNOVN(tdcrisp)  or  vmccr  O  "YES"  or  vpmrt  O  "YES") 
and  KNOWN (tdsow) 

THEN:  PERFORM  ADDTASK 

IF  vfollow  -  "NO"  and  vscomp  -  "MAJOR"  THEN 
duration  -  71 
ELSE 

duration  -  62 
END  IF 

IF  vqrc  -  "YES"  THEN 

IF  vscomp  -  "MAJOR"  THEN 
duration  -  28 
ELSE 

duration  -  21 
END  IF 
END  IF 

IF  vjoint  O  "NONE"  THEN 
IF  vscomp  -  "MAJOR"  THEN 
duration  -  duration  +  21 
ELSE 

duration  -  duration  +  14 
END  IF 
END  IF 

CURRTASK . DUR  -  TOSTR(duration, 5 ,0) 

CURRTASK . DESCR  -  "DATA  PACKAGE  PREPARATION" 

CURRTASK. OPR  -  "RWB  " 

tdata  -  CURRTASK. ID 
IF  KNOWN (tdcrisp)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdcrisp 
CURRLINK. SUCC  -  tdata 
ENDIF 

ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdsow 
CURRLINK. SUCC  -  tdata 


REASON:  Data  Package  Preparation  follows  development  of  the 

CRISP  (if  used)  and  the  Draft  SOW.  Its  duration  depends 
on  type  of  effort,  System  Complexity,  and  Joint  service 
involvement . 

COMMENT:  Data  Package  Preparation.  Source:  Linda  Lorenz, 
X56421. 

Event  28  in  RW  Phase  I  network,  30  Aug  85. 


RSSS 

PRIORITY:  80 

TEST:  E 

IF:  vsssn  -  "YES"  and  KNOWN(tdsow) 

THEN:  PERFORM  ADDTASK 

duration  -  42 

IF  vcntrct  -  "SOLE  SOURCE"  THEN 
duration  -  duration  -  15 
ENDIF 

CURRTASK . DUR  -  T0STR( duration, 5 ,0) 

CURRTASK . DESCR  -  "SOURCES  SOUGHT  SYNOP" 

CURRTASK. OPR  -  "PM  &  RWK 
tsss  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tdsow 
CURRLINK. SUCC  -  tsss 

REASON:  The  Sources  Sought  Synopsis  follows  the  Draft  SOW.  Its 
duration  depends  on  the  type  of  contract  used.  This  task 
is  not  needed  unless  the  RFP  exceeds  $25K  or  RDTE  money 
is  involved. 

COMMENT:  Sources  Sought  Synopsis.  Sources:  Carolyn  Bowling, 
x52085;  Jim  Shaeffer,  x52336. 

Event  29  in  RW  Phase  I  network,  30  Aug  85. 


RSSPP 

PRIORITY:  70 
TEST:  E 

IF:  vfollow  -  "NO"  and  vcntrct  O  "SOLE  SOURCE"  and 

KNOWN (tasp) 

THEN:  PERFORM  ADDTASK 

IF  vrdte  >  100  or  vprod  >  500  THEN 
duration  -  "  45" 

ELSE 

IF  vrdte  >  50  or  vprod  >  100  THEN 
duration  -  *  30" 

ELSE 

duration  -  "  15" 

ENDIF 

ENDIF 

CURRTASK. DUR  -  duration 
CURRTASK. DESCR  -  "SS  PLAN  PREP 
CURRTASK. OPR  -  "PM 


tsspp  -  CURRTASK.ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PREO  -  tasp 
CURRLINK. SUCC  -  tsspp 

REASON:  Source  Selection  Plan  Preparation  follows  the 

Acquisition  Strategy  Panel.  Its  duration  depends  on  the 
type  and  amount  of  dollars  spent.  This  task  is  not  used 
for  sole  source  procurements . 

COMMENT:  Source  Selection  Plan  Preparation.  Source:  Ed  Martin, 
X56624. 

Event  30  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RSSPA 

PRIORITY:  70 
TEST:  E 

IF:  KNOWN (tsspp) 

THEN:  PERFORM  ADDTASK 

IF  vrdte  >  100  or  vprod  >  500  THEN 
duration  -  "  30" 

ELSE 

IF  vrdte  >  50  or  vprod  >  100  THEN 
IF  vssd  -  «YES"  THEN 
duration  -  *  15" 

ELSE 

duration  -  *  13" 

END  IF 
ELSE 

duration  -  "  5" 

ENDIF 
END  IF 

CURRTASK . DUR  -  duration 

CURRTASK . DESCR  -  "SS  PLAN  APPROVAL 

CURRTASK. OPR  -  "PM 

tsspa  -  CURRTASK.ID 

ATTACH  1  TO  CURRLINK 

CURRLINK. PRED  -  tsspp 

CURRLINK. SUCC  -  tsspa 

REASON:  Source  Selection  Plan  Approval  follows  Source  Selection 
Plan  Preparation.  Its  duration  depends  on  the  type  and 
amount  of  dollars  spent.  This  task  Is  not  used  for  sole 
source  procurements. 

COMMENT:  Source  Selection  Plan  Approval.  Source  Ed  Mai  tin, 
x56624. 

Event  30  in  RW  Phase  I  network,  30  Aug  85 


RULE:  RJAP 

PRIORITY:  70 
TEST:  E 

IF:  vcntrct  -  "SOLE  SOURCE"  and  vfollow  -  "NO"  and 

KNOWN(tasp) 


THEN:  PERFORM  ADDTASK 

CURRTASK . DUR  -  *  5" 

CURRTASK . DESCR  -  "J&A  PREP 
CURRTASK . OPR  -  "RWK 
tj*p  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tasp 
CURRLINK. SUCC  -  tjap 

REASON:  Justification  &  Approval  Preparation  follows  the 

Acquisition  Strategy  Panel.  Its  duration  is  5  days. 

This  task  is  not  needed  unless  a  sole  source  procurement 
is  planned. 

COMMENT:  J&A  Preparation.  Sources:  A1  Miller,  X58328;  Jim 
Shaeffer,  x52336. 

Event  31  in  RV  Phase  I  network,  30  Aug  85. 


RULE:  RPBASE 

PRIORITY:  70 
TEST:  E 

IF'  KNOWN(tasp)  or  (KNOWN (tsched)  and  vinscope  -  "YES") 
THEN:  PERFORM  ADDTASK 

IF  vjoint  -  "NONE"  THEN 
duration  -  *  65" 

ELSE 

duration  -  *  130" 

END  IF 

CURRTASK. DUR  -  duration 
CURRTASK. DESCR  -  "PROGRAM  BASELINE 
CURRTASK. OPR  -  "PM 
tpbase  -  CURRTASK. ID 
IF  KNOWN (tasp)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tasp 
CURRLINK . SUCC  -  tpbase 
ELSE 

ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tsched 
CURRLINK . SUCC  -  tpbase 
END  IF 

REASON:  The  Program  Baseline  follows  the  Acquisition  Strategy 
Panel  (if  used)  or  Program  Schedules.  Its  duration 
depends  on  Joint  service  involvement. 

COMMENT:  Program  Baseline.  Sources:  LTC  Hollingsworth,  x54811. 
Event  33  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RCBASE 

PRIORITY:  70 
TEST:  E 

IF:  KNOWN(tasp)  or  (KNOWN(tcostest)  and  vinscope  -  "YES") 

THEN:  PERFORM  ADDTASK 
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duration  -  25 
IF  vecbase  -  "YES’  THEN 
duration  -  15 
ELSE 

duration  -  10 
END  IF 

IF  vpdes  -  "SAR"  THEN 
duration  -  duration  +  10 
ELSE 

IF  vpdes  -  "DESIGNATED"  THEN 
duration  -  duration  +  7 
ELSE 

duration  -  duration  +  5 
END  IF 
ENDIF 

IF  vjolnt  O  "NONE"  THEN 
duration  -  duration  +  5 
ENDIF 

CURRTASK . DUR  -  T0STR(duratlon,5,0) 

CURRTASK . DESCR  -  "COST  BASELINE 

CURRTASK. OPR  -  "PH  &  RWPE 
tcbase  -  CURRTASK. ID 
IF  KNOWN (tasp)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tasp 
CURRLINK. SUCC  -  tcbase 
ELSE 

ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tcostest 
CURRLINK. SUCC  -  tcbase 
ENDIF 

REASON:  The  Cost  Baseline  follows  the  Acquisition  Strategy  Panel 
(If  used)  or  the  Cost  Estimate.  Its  duration  depends  on 
Joint  service  involvement. 

COMMENT:  Cost  Baseline.  Sources:  LT  Karpovich,  x54011. 

Event  34  In  RW  Phase  I  network,  30  Aug  85. 


RULE:  RAPA 

PRIORITY:  70 
TEST:  E 

IF:  KNOWN (tasp) 

THEN:  PERFORM  ADDTASK 

IF  vrdte  >  5  THEN 
duration  -  "  124" 

ELSE 

IF  vprod  >  5  THEN 
duration  -  *  4" 

ELSE 

duration  -  "  0" 

ENDIF 
ENDIF 


CURRTASK . DUR  -  duration 

CURRTASK . DESCR  -  "AP  APPROVAL  " 

CURRTASK. OPR  -  "PM  &  RWK 
tapa  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tasp 
CURRLINK. SUCC  -  tapa 

REASON:  Acquisition  Plan  Approval  follows  the  Acquisition 

Strategy  Panel.  Its  duration  depends  on  the  type  and 
amount  of  dollars  spent. 

COMMENT:  Acquisition  Plan  Approval.  Sources:  Jim  Shaeffer, 
x52336. 

Event  35  in  RW  Phase  I  network,  30  Aug  85. 


RULE :  RFSOW 

PRIORITY:  70 
TEST:  E 

IF:  (KNOWN(tdcrisp)  or  vmccr  O  "YES"  or  vpmrt  O  "YES") 

and  (KNOWN (tapa)  or  vinscope  -  "YES")  and 
KNOWN (tdilsp)  and  (KNOWN(tdrfp)  or 
(vdrfpn  O  "YES"  and  (KNOWN(tsss)  or 

(vsssn  O  "Y£S"and  KNOWN(tdsow)))))  and 
(KNOWN(twbsa)  or  (vrdte  <-  2  and  vprod  <-2)) 

THEN:  PERFORM  ADDTASK 

CURRTASK. DUR  -  "  40" 

CURRTASK. DESCR  -  "FINAL  SOW 
CURRTASK. OPR  -  "PM  &  RWE 
tf sow  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdilsp 
CURRLINK. SUCC  -  tfsow 
IF  KNOWN(tdcrisp)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdcrisp 
CURRLINK. SUCC  -  tfsow 
END  IF 

IF  KNOWN (tapa)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tapa 
CURRLINK. SUCC  -  tfsow 
ENDIF 

IF  KNOWN(tdrfp)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdrfp 
CURRLINK. SUCC  -  tfsow 
ELSE 

IF  KNOWN(tsss)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tsss 
CURRLINK. SUCC  -  tfsow 
ELSE 


ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdsow 
CURRLINK. SUCC  -  tfsow 
END  IF 
ENDIF 

IF  KNOWN(twbsa)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tvbsa 
CURRLINK. SUCC  -  tfsow 
ENDIF 

REASON:  The  Final  Statement  of  Work  follows  the  Draft  CRISP  (if 
used),  Acquisition  Plan  Approval  (if  used),  the  Draft  RFP 
(if  used)  and  approval  of  the  Work  Breakdown  Structure 
(if  used),  or  the  Draft  Statement  of  Work.  Its  duration 
is  40  days. 

COMMENT:  Final  SOW.  Sources:  RW  Phase  I  Scheduling  Guide. 

Event  36  in  RW  Phase  I  network,  30  Aug  85. 


RDRFP 

PRIORITY:  70 
TEST:  E 

IF:  vdrfpn  -  "YES"  and  KNOWN(tdspec)  and  KNOWN( tdsow)  and 

(KNOWN (tdata)  or  vdata  O  "YES")  and 
(KNOWN(tasp)  or  (vinscope  -  "YES"  and 
(KNOWN(tsss)  or  vsssn  O  "YES"))) 

THEN:  PERFORM  ADDTASK 

CURRTASK .  DUR  -  "  17" 

CURRTASK . DESCR  -  "DRAFT  RFP 
CURRTASK. OPR  -  "PM  &  RWK 
tdrfp  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdspec 
CURRLINK. SUCC  -  tdrfp 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdsow 
CURRLINK. SUCC  -  tdrfp 
IF  KNOWN (tdata)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdata 
CURRLINK. SUCC  -  tdrfp 
ENDIF 

IF  KNOWN (tasp)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tasp 
CURRLINK. SUCC  -  tdrfp 
ELSE 

IF  KNOWN(tsss)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tsss 
CURRLINK. SUCC  -  tdrfp 
ENDIF 


ENDIF 

REASON:  The  Draft  Request  For  Proposal  follows  the  Draft 

Statement  of  Vork,  the  Draft  Specification,  Data  Package 
Preparation  (if  used)  and  the  Acquistion  Strategy  Panel 
(if  used).  Its  duration  is  17  days  including  response 
time.  This  task  is  not  used  for  sole  source  procurements 
or  competitive  procurements  less  than  $25M. 

COMMENT:  Draft  RFP.  Sources:  Carolyn  Bowling,  x52085;  Jim 
Shaeffer,  x52336. 

Event  37  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RFSPEC 

PRIORITY:  80 
TEST:  E 

IF:  KNOWN(tdilsp)  and 

(KNOWN(tdcrisp)  or  vmccr  O  "YES"  or  vpmrt  O  "YES")  and 
((KNOWN (tdspec)  and  vdrfpn  O  "YES")  or  KNOWN(tdrfp)) 
THEN:  PERFORM  ADDTASK 

duration  -  150 
IF  vscomp  -  "MINOR"  THEN 
duration  -  duration  -  15 
ENDIF 

IF  vjoint  -  "NONE"  THEN 
duration  -  duration  -  25 
ENDIF 

CURRTASK . DUR  -  T0STR( duration, 5,0) 

CURRTASK. DESCR  -  "FINAL  SPEC 
CURRTASK. OPR  -  "PM  &  RWE 
tfspec  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tdilsp 
CURRLINK. SUCC  -  tfspec 
IF  KNOWN (tdcrisp)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdcrisp 
CURRLINK. SUCC  -  tfspec 
ENDIF 

IF  KNOWN(tdrfp)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdrfp 
CURRLINK. SUCC  -  tfspec 
ELSE 

ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdspec 
CURRLINK. SUCC  -  tfspec 
ENDIF 

REASON:  The  Final  Specification  follows  the  draft  ILSP  the  draft 
CRISP  (if  used),  and  the  Draft  RFP  (if  used)  or  the  Draft 
Specification.  Its  duration  depends  on  System  Complexity 
and  Joint  service  involvement. 

COMMENT:  Final  Specification.  Sources:  RW  Phase  I  Scheduling 
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Guide . 

Event  38  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RJAA 

PRIORITY:  70 
TEST:  E 

IF:  KNOWN(tjap)  and  KNOWN(tapa) 

THEN:  PERFORM  ADDTASK 

duration  -  20 

IF  vrdte  >  10  or  vprod  >  10  THEN 
IF  vcntrv  -  "YES"  THEN 
duration  -  duration  +  90 
ELSE 

duration  -  duration  +  60 
END  IF 
ELSE 

duration  -  duration  +  30 
ENDIF 

CURRTASK . DUR  -  TOSTR(duration, 5 ,0) 

CURRTASK . DESCR  -  "J&A  APPROVAL 
CURRTASK. OPR  -  "RWK 
tjaa  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tjap 
CURRLINK. SUCC  -  tjaa 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tapa 
CURRLINK. SUCC  -  tjaa 

REASON:  Justification  &  Approval  Approval  follows  Justification 
&  Approval  Preparation  and  Acquisition  Plan  Approval. 

Its  duration  depends  on  the  amount  of  dollars  spent. 
COMMENT:  J&A  Preparation.  Sources:  A1  Miller,  x58328;  Jim 
Shaeffer,  x52336. 

Event  39  in  RW  Phase  I  network,  30  Aug  85. 


RULE: 


RFRM117 
PRIORITY: 
TEST :  E 

IF: 


70 


THEN: 


(KNOWN (tdd2 54)  or  vclass  -  "UNCLASSIFIED")  and 
KNOWN (ttemp)  and  (KNOWN(tmoa)  or  vmoa  -  "NONE")  and 
KNOWN(tsafe)  and  KNOWN(tpbase)  and  KNOWN(tcbase)  and 
KNOWN(tfsow)  and  KNOWN(tpad)  and  KNOWN(tpmp)  and 
KNOWN(tfspec)  and  (KNOWN(tjaa)  or 

vcntrct  O  "SOLE  SOURCE"  or  vfollow  -  "YES")  and 
(vdrfpn  -  "YES"  or  KNOWN(tdata)  or  vdata  O  "YES") 
PERFORM  ADDTASK 
CURRTASK. DUR  -  "  15" 

CURRTASK. DESCR  -  "ASD  FORM  117 
CURRTASK. OPR  -  "PM 
tfornll7  -  CURRTASK. ID 


IF  KNOWN (tdd2 54)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tdd254 
CURRLINK. SUCC  -  tformll7 
END  IF 

ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  ttemp 
CURRLINK. SUCC  -  tfonnll7 
IF  KNOWN (tmoa)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tmoa 
CURRLINK. SUCC  -  tformll7 
ENDIF 

ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tsafe 
CURRLINK. SUCC  -  tformll7 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tpbase 
CURRLINK. SUCC  -  tformll7 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tcbase 
CURRLINK. SUCC  -  tformll7 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tfsow 
CURRLINK . SUCC  -  tformll7 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tpad 
CURRLINK. SUCC  -  tformll7 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tpmp 
CURRLINK. SUCC  -  tformll7 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tfspec 
CURRLINK . SUCC  -  tformI17 
IF  KNOWN(tjaa)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tjaa 
CURRLINK. SUCC  -  tformll7 
ENDIF 

IF  vdrfpn  O  "YES"  and  vdata  -  "YES"  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tdata 
CURRLINK. SUCC  -  tformll7 
ENDIF 

REASON:  ASD  Form  117  coordination  and  approval  follows  DD254  (If 
used),  TEMP,  MOA/MOU  (If  used),  Safety,  ASP  (If  used), 
Data  Package  (If  used),  Program  Baseline,  Cost  Baseline, 
Final  SOW,  Draft  RFP  (If  used),  and  Final  Specification. 
Its  duration  Is  15  days. 

COMMENT:  ASD  Form  117.  Sources:  LTC  Hollingsworth,  x54811. 
Event  40  In  RW  Phase  I  network,  30  Aug  85. 
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RRFPPP 

PRIORITY: 


TEST: 

IF: 

THEN: 


KNOWN (tforall7) 
PERFORM  ADDTASK 
CURRTASK . DUR  -  " 


CURRTASK . DESCR  -  "RFP  PACKAGE  PREP 

CURRTASK. OPR  -  "RWK 

trfppp  -  CURRTASK. ID 

ATTACH  1  TO  CURRLINK 

CURRLINK . PRED  -  tforall7 

CURRLINK. SUCC  -  trfppp 

REASON:  RFP  Package  Preparation  follows  ASD  Fora  117 

coordination  and  approval.  Its  duration  Is  14  days. 

COMMENT:  RFP  Package  Preparation.  Sources:  Jim  Shaeffer, 
x52336. 

Event  41  In  RW  Phase  I  network,  30  Aug  85. 


RSSSP 

PRIORITY: 


TEST: 

IF: 


THEN: 


vfollow  -  "NO"  and  vcntrct  O  "SOLE  SOURCE"  and 
KNOWN (tasp) 

PERFORM  ADDTASK 

IF  vrdte  >  100  or  vprod  >  500  THEN 
duration  -  "  45" 

ELSE 

IF  vrdte  >  50  or  vprod  >  100  THEN 
duration  -  "  30" 


duration 

ELSE 

duration 

ENDIF 

ENDIF 

CURRTASK. DUR 


CURRTASK. DUR  -  duration 

CURRTASK. DESCR  -  "SS  STANDARDS  PREP 

CURRTASK. OPR  -  "PM 

tsssp  -  CURRTASK. ID 

ATTACH  1  TO  CURRLINK 

CURRLINK. PRED  -  tasp 

CURRLINK. SUCC  -  tsssp 

REASON:  Source  Selection  Standards  Preparation  follows  the 

Acquisition  Strategy  Panel.  Its  duration  depends  on  the 
type  and  amount  of  dollars  spent.  This  task  is  not  used 
for  sole  source  procurements. 

COMMENT:  Source  Selection  Standards  Preparation.  Source:  Ed 
Martin,  x56624. 

Event  43  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RSSSA 

PRIORITY:  70 
TEST:  E 

IF:  KNOWN(tsssp)  and  KNOWN(tsspa) 

THEN :  PERFORM  ADDTASK 

IF  vrdte  >  100  or  vprod  >  500  THEN 
duration  -  "  30* 

ELSE 

IF  vrdte  >  50  or  vprod  >  100  THEN 
IF  vssd  -  "YES"  THEN 
duration  -  *  15" 

ELSE 

duration  -  *  13" 

END  IF 
ELSE 

duration  -  "  5" 

END  IF 
ENDIF 

CURRTASK.DUR  -  duration 

CURRTASK. DESCR  -  "SS  STANDARDS  APPROVAL 

CURRTASK . OPR  -  "PM 

tsssa  -  CURRTASK. ID 

ATTACH  1  TO  CURRLINK 

CURRLINK . PRED  -  tsssp 

CURRLINK. SUCC  -  tsssa 

ATTACH  1  TO  CURRLINK 

CURRLINK . PRED  -  tsspa 

CURRLINK. SUCC  -  tsssa 

REASON:  Source  Selection  Standards  Approval  follows  Source 
Selection  Standards  Preparation  and  Source  Selection 
Plan  Approval.  Its  duration  depends  on  the  type  and 
amount  of  dollars  spent.  This  task  is  not  used  for  sole 
source  procurements. 

COMMENT:  Source  Selection  Plan  Approval.  Source:  Ed  Martin, 
x56624. 

Event  43  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RSSP 

PRIORITY:  70 
TEST:  E 

IF:  KNOUN(tsspp) 

THEN:  PERFORM  ADDTASK 

duration  -  "  10" 

IF  vrdte  >  50  or  vprod  >  100  THEN 
IF  vssd  O  "YES"  THEN 
duration  -  "  20" 

ENDIF 

ENDIF 

CURRTASK.DUR  -  duration 

CURRTASK. DESCR  -  "SS  PROCEDURES  " 


CURRTASK . OPR  -  "PH 
tssp  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tsspp 
CURRLINK. SUCC  -  tssp 

REASON:  Source  Selection  Procedures  follows  Source  Selection 

Plan  Preparation.  Its  duration  depends  on  the  type  and 
amount  of  dollars  spent.  This  task  is  not  used  for  sole 
source  procurements. 

COMMENT:  Source  Selection  Plan  Approval.  Source:  Ed  Martin, 
X56624. 

Event  43  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RASDREV 

PRIORITY:  70 
TEST :  E 

IF:  KNOWN (trfppp) 

THEN:  PERFORM  ADDTASK 

duration  -  "  15" 

IF  (vrf p/1000)  >  25  THEN 
duration  -  *  20" 

ENDIF 

CURRTASK. DUR  -  duration 

CURRTASK. DESCR  -  "3-LTR  &  ASD  REVIEWS 

CURRTASK. OPR  -  "PM 

tasdrev  -  CURRTASK. ID 

ATTACH  1  TO  CURRLINK 

CURRLINK. PRED  -  trfppp 

CURRLINK. SUCC  -  tasdrev 

REASON:  Three -letter  and  ASD  Reviews  follow  RFP  Package 

Preparation.  Its  duration  depends  on  the  RFP  value. 
COMMENT:  Three -letter  and  ASD  Reviews.  Source:  Jim  Shaeffer, 
X52336. 

Event  44  in  RW  Phase  I  network,  30  Aug  85. 


RULE:  RAFSCREV 

PRIORITY:  70 
TEST:  E 

IF:  KNOWN( tasdrev)  and  (vrfp/1000)  >  75 

THEN:  PERFORM  ADDTASK 

CURRTASK. DUR  -  "  25" 

CURRTASK. DESCR  -  "AFSC  REVIEW 
CURRTASK. OPR  -  "PM 
tafscrev  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tasdrev 
CURRLINK. SUCC  -  tafscrev 

REASON:  The  AFSC  Review  follows  the  Three -letter  and  ASD 

Reviews.  Its  duration  is  25  days.  This  task  is  not 
needed  unless  the  RFP  Package  exceeds  $75M. 


COMMENT:  AFSC  Review.  Source:  Jim  Shaeffer,  x52336. 
Event  44  in  RW  Phase  I  network,  30  Aug  85. 


RRFPR 

PRIORITY:  70 

TEST:  E 

IF:  (KNOWN(tsspa)  or  vfollow  -  "YES"  or 

vcntrct  -  "SOLE  SOURCE"  or  vinscope  -  "YES")  and 
KNOWN (tasdrev) 

THEN:  PERFORM  ADDTASK 

IF  vcntrct  -  "COMPETITIVE"  THEN 
IF  (vrfp/1000)  <3.5  THEN 
duration  -  "  35" 

ELSE 

duration  -  "  45" 

ENDIF 
END  IF 

IF  vcntrct  -  "SOLE  SOURCE"  THEN 
IF  (vrfp/1000)  <  25  THEN 
duration  -  "  35" 

ELSE 

duration  -  "  45" 

ENDIF 

ENDIF 

IF  vcntrct  -  "LONG  LEAD"  or  \ 

vcntrct  -  "LETTER  CONTRACT"  or  \ 
vcntrct  -  "UNPRICE  ORDER  UNDER  BOA"  THEN 
duration  -  "  30" 

ENDIF 

IF  vcntrct  -  "PRICED  ORDER  UNDER  BOA"  THEN 
duration  -  "  45" 

ENDIF 

IF  vcntrct  -  "ONE  STEP  SEALED  BID"  THEN 
duration  -  "  60" 

ENDIF 

IF  vcntrct  -  "TWO  STEP  SEALED  BID"  THEN 
duration  -  "  45" 

ENDIF 

CURRTASK.DUR  -  duration 
CURRTASK . DESCR  -  "RFP  RELEASE 
CURRTASK.OPR  -  "RWK 
trfpr  -  CURRTASK. ID 
ATTACH  1  TO  CURRLINK 
CURRLINK . PRED  -  tasdrev 
CURRLINK. SUCC  -  trfpr 
IF  KNOWN(tsspa)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tsspa 
CURRLINK. SUCC  -  trfpr 
ENDIF 

REASON:  RFP  Release  follows  the  Three -letter  and  ASD  Reviews  and 


SS  Plan  Approval  (If  used).  Its  duration  depends  on  the 
Type  of  Contract  and  the  RFP  value. 

COMMENT:  RFP  Release.  Sources:  Jim  Shaeffer,  x52336,  Jim 
Chapman,  x?????,  and  Myron  Phillips,  x?????. 

Event  45  In  RW  Phase  I  network,  30  Aug  85. 


RULE:  RCPROPR 

PRIORITY:  70 
TEST :  E 

IF:  KNOWN(trfpr) 

THEN:  PERFORM  ADDTASK 

IF  ventre t  -  "COMPETITIVE"  THEN 
IF  (vrfp/1000)  <3.5  THEN 
duration  -  "  50" 

ELSE 

duration  -  "  60" 

ENDIF 
END  IF 

IF  ventret  -  "SOLE  SOURCE"  THEN 
IF  (vrfp/1000)  <25  THEN 
duration  -  "  50" 

ELSE 

duration  -  "  60" 

ENDIF 

ENDIF 

IF  ventret  -  "LONG  LEAD"  or  \ 

ventret  -  "LETTER  CONTRACT"  THEN 
duration  -  "  50" 

ENDIF 

IF  ventret  -  "UNPRICE  ORDER  UNDER  BOA"  THEN 
duration  -  "  30" 

ENDIF 

IF  ventret  -  "PRICED  ORDER  UNDER  BOA"  THEN 
duration  -  "  60" 

ENDIF 

IF  ventret  -  "ONE  STEP  SEALED  BID"  THEN 
duration  -  "  45" 

ENDIF 

IF  ventret  -  "TWO  STEP  SEALED  BID"  THEN 
duration  -  "  60" 

ENDIF 

CURRTASK. DUR  -  duration 

CURRTASK . DESCR  -  "CONTRACTOR  RESPONSE 

CURRTASK . OPR  -  "CONTRACTOR  " 

tepropr  -  CURRTASK. ID 

ATTACH  1  TO  CURRLINK 

CURRLINK . PRED  -  trfpr 

CURRLINK. SUCC  -  tepropr 

REASON:  Contractor  Response  follows  the  RFP  Release.  Its 

duration  depends  on  the  Type  of  Contract  and  the  RFP 
value . 
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COMMENT:  Contractor  Response.  Sources:  Jim  Shaeffer,  x52336, 
Jim  Chapman,  x?????,  and  Myron  Phillips,  x?????. 

Event  46  in  RW  Phase  I  network,  30  Aug  85. 


RULE: 


RSS 

PRIORITY:  70 
TEST:  E 

IF:  (KNOWN (tafscrev)  or  (vrfp/1000)  <-  75)  and 

KNOWN (tcpropr)  and  ((KNOWN(tsssa)  and  KNOWN(tssp))  or 
ventre t  -  "SOLE  SOURCE"  or  vfollow  -  "YES"  or 
vinscope  -  "YES") 

THEN:  PERFORM  ADDTASK 

IF  ventret  -  "COMPETITIVE"  THEN 
IF  (vrfp/1000)  <3.5  THEN 
duration  -  "  37* 

ELSE 

IF  (vrfp/1000)  <  25  THEN 
duration  -  "  65" 

ELSE 

duration  -  "  67" 

ENDIF 
END  IF 
ENDIF 

IF  ventret  -  "SOLE  SOURCE"  THEN 
IF  (vrfp/1000)  <  25  THEN 
duration  -  "  68" 

ELSE 

duration  -  "  80" 

ENDIF 

ENDIF 

IF  ventret  -  "LONG  LEAD"  or  \ 

ventret  -  "LETTER  CONTRACT"  or  \ 
ventret  -  "UNPRICE  ORDER  UNDER  BOA"  THEN 
duration  -  "  68" 

ENDIF 

IF  ventret  -  "PRICED  ORDER  UNDER  BOA"  THEN 
duration  -  "  95" 

ENDIF 

CURRTASK . DUR  -  duration 
CURRTASK . DESCR  -  "SOURCE  SELECTION 

CURRTASK. OPR  -  "PM 
tss  -  CURRTASK. ID 
IF  KNOWN( tafscrev)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tafscrev 
CURRLINK. SUCC  -  tss 
ENDIF 

IF  KNOWN(tsssa)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tsssa 
CURRLINK. SUCC  -  tss 


RULE: 


END  IF 

IF  KNOWN(tssp)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK .  PRED  -  tssp 
CURRLINK. SUCC  -  tss 
END  IF 

ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tcpropr 
CURRLINK. SUCC  -  tss 

REASON:  Source  Selection  follows  the  AFSC  Review  (if  used), 
Source  Selection  Standards  Approval  (if  used),  Source 
Selection  Procedures  (if  used),  and  Contractor  Response. 
Its  duration  depends  on  the  Type  of  Contract  and  the  RFP 
value . 

COMMENT:  Source  Selection.  Sources:  Ed  Martin,  x56623;  Jim 
Shaeffer,  x52336;  Jim  Chapman,  x?????;  and  Myron 
Phillips,  x?????. 

Event  47  in  RW  Phase  I  network,  30  Aug  85. 


RAWARD 

PRIORITY:  70 
TEST:  E 

IF:  KNOWN (tc lisp)  and  KNOWN(tss)  and 

( KNOWN (tccrisp)  or  vmccr  O  "YES"  or  vpmrt  O  "YES") 
THEN:  PERFORM  ADDTASK 

IF  ventre t  -  "COMPETITIVE"  THEN 
IF  (vrfp/1000)  <3.5  THEN 
duration  -  "  32" 

ELSE 

duration  -  "  43" 

ENDIF 

ENDIF 

IF  ventret  -  "SOLE  SOURCE"  THEN 
IF  (vrfp/1000)  <  25  THEN 
duration  -  *  27" 

ELSE 

duration  -  "  35" 

ENDIF 

ENDIF 

IF  ventret  -  "LONG  LEAD"  or  \ 

ventret  -  "LETTER  CONTRACT"  or  \ 
ventret  -  "UNPRICE  ORDER  UNDER  BOA"  THEN 
duration  -  "  27" 

ENDIF 

IF  ventret  -  "PRICED  ORDER  UNDER  BOA"  THEN 
duration  -  "  35" 

ENDIF 

IF  ventret  -  "ONE  STEP  SEALED  BID"  THEN 
duration  -  "  54" 

ENDIF 

IF  ventret  -  " 


TWO  STEP  SEALED  BID"  THEN 


duration  -  *  64" 

END  IF 

CURRTASK . DUR  -  duration 
CURRTASK . DESCR  -  "CONTRACT  AWARD 
CURRTASK. OPR  -  "RWK 
IF  vaward  O  "  "  THEN 

CURRTASK. US  -  vaward 
END  IF 

taward  -  CURRTASK. ID 
ATTACH  I  TO  CURRLINK 
CURRLINK . PRED  -  tss 
CURRLINK. SUCC  -  taward 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tcilsp 
CURRLINK. SUCC  -  taward 
IF  KNOWN(tccrisp)  THEN 
ATTACH  1  TO  CURRLINK 
CURRLINK. PRED  -  tccrisp 
CURRLINK. SUCC  -  taward 
ENDIF 

REASON:  Contract  Award  follows  Source  Selection  (if  used)  or 

Contractor  Response.  Coordination  of  the  CRISP  and  ILSP 
are  included  for  network  completeness.  However,  they 
extend  into  the  next  stage.  Its  duration  depends  on  the 
Type  of  Contract  and  the  RFP  value. 

COMMENT:  Contract  Award.  Sources:  Jim  Shaeffer,  x52336,  Jim 
Chapman,  x?????,  and  Kyron  Phillips,  x????7. 

Event  48  in  RW  Phase  I  network,  30  Aug  85. 


ISA  EVALUATION 


1.  To  what  degree  do  you  believe  that  the  concept  of  an  intelligent 
scheduling  assistant  as  demonstrated  by  ISA  is  valid? 

a.  Strongly  agree:  recommend  developing  operational  system 

b.  Agree:  recommend  further  research 

c.  Neutral 

d.  Disagree:  little  merit 

e.  Strongly  disagree:  abandon  concept  due  to  poor  results 

2.  How  would  you  evaluate  the  user  interface? 

a.  Excellent  potential:  extremely  user-friendly 

b.  Good  potential:  user-friendly 

c .  Neutral 

d.  Poor  potential:  not  user-friendly 

e.  Bad  potential:  would  not  be  used 

3.  How  would  you  evaluate  the  results  of  the  system? 

a.  Excellent:  schedules  are  as  good  as  best  people  do 

b.  Good:  schedules  are  reasonable 

c.  Neutral 

d.  Poor:  schedules  have  deficiencies 

e.  Bad:  schedules  are  not  usable 

A.  To  what  degree  do  you  believe  that  an  intelligent  schedule  assist¬ 
ant  is  an  improvement  to  model  networks? 

a.  Strongly  agree:  much  better 

b.  Agree:  better 

c.  Neutral 

d.  Disagree:  worse 

e.  Strongly  disagree:  much  worse 


5.  What  improvements  would  you  recommend  for  the  intelligent  model 
network  concept. 


6. 


Have  you  ever  used  network  scheduling  before? 


a.  More  than  3  times 

b.  One  to  three  times 

c.  Never  - 

7.  Have  you  ever  used  automated  project  management  tools  (CSNAS,  Time¬ 
line,  etc.)?  If  yes,  please  list  project  management  tools  that  you  have 
used: 


8.  Have  you  ever  used  model  networks  (RW  Phase  I,  POINTS,  CSNAS)?  If 
yes,  please  list  the  model  networks,  number  of  times  used,  and  results 
of  use: 


9.  Do  you  believe  that  network  scheduling  has  merit  (yes/no)? 

10.  What  further  research  In  this  area  would  you  support  (select  all 
that  apply) : 

a.  Development  of  a  scheduler  which  generates  networks  using 
strictly  a  list  of  tasks,  requirements  and  relationships. 

b.  Development  of  an  analyst  which  makes  recommendations  for 
modifying  networks  to  solve  resource  and  timing  problems. 

c.  Development  of  an  assistant  which  automatically  modifies  net¬ 
works  at  the  users  directions  (determines  how  to  reorder  the 
network  when  tasks  are  added  or  relationships  are  modified)  . 

d.  Please  list  any  other  you  can  think  of. 


Appendix  El  AFALC  Utter 


DEPARTMENT  OF  THE  AIR  FORCE 

HEADQUARTERS  AIR  FORCE  ACQUISITION  LOGISTICS  CENTER 
WRIOHT-RATTERSON  AIR  FORCE  BASE.  OHIO  4S4SS-SOOO 


FROM:  AFALC/LSL 

SUBJECT:  DEMONSTRATION  OF  AI 

TO:  CAPTAIN  MORAN 

1.  Ne  were  very  impressed  by  the  demonstration  of  your  artificial 
Intelligence/expert  system  for  tailoring  a  model  network.  He  had 
envisioned  commissioning  a  pilot  system,  but  your  effort  saved  us 
both  the  cost  and  the  effort  of  contracting  for  a  pilot  system. 

2.  This  office  created  a  series  of  model'  networks/schedules  for 
the  Integration  of  acquisition  logistics  into  the  development  and 
production  of  weapons  systems.  For  several  years  our  problem  has 
been  that  there  were  not  enough  experts  to  help  all  of  the 
acquisition  logistics  managers  and  the  managers  were  not 
sufficiently  expert  in  all  of  the  separate  Integrated  logistics 
support  (ILS)  areas  to  tailor  their  own  networks.  Your  system 
demonstrates  how  the  experts  knowledge  in  an  area  can  be  captured 
in  software  to  make  their  knowledge  available  to  all  of  the 
managers. 

3.  As  a  result  of  your  demonstrations,  granted  us  from  your  own 
time,  this  office  has  now  started  working  with  AFLC/MM-AI  toward 
the  possible  expansion  of  your  system  into  the  entire  acquisition 
logistics  arena.  If  our  effort  is  as  successful  as  your 
demonstrated  system,  the  resultant  software  will  eventually  be 
deployed  to  all  AFLC  air  logistics  centers  and  AFSC  product 
divisions  for  use  by  all  acquisition  logistics  managers. 

4.  We  thank  you  for  the  extra  time  you  have  dedicated  to  us  in 
providing  demonstrations  of  your  system.  We  especially  thank  you 
for  providing  us  with  a  pilot  system  that  demonstrates  how  AI  can 
be  used  to  Improve  logistics  within  the  weapons  system  program 
offices. 

ALBERT  L.  CLARK 
CSNAS  PROGRAM  MANAGER 
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